Padrões GoF

Jobson Ronan {jrjsj@cin.ufpe.br}

Padrões Estruturais Tratam de compor classes e objetos para formar estruturas

grandes e complexas

Padrão Adapter (Wrapper)

Padrão Adapter Intenção

Converter a interface de uma classe em outra interface, esperada pelos clientes. Permite que classes com interfaces incompatíveis trabalhem em conjunto.

Também conhecido como Wrapper

Motivação Algumas vezes uma classe (de um toolkit) não é reusável porque

sua interface não é compatível com a interface de uma aplicação de um domínio específico.

A solução é criar um objeto adaptador, que encapsule e filtre as especificidades da classe adaptada, fornecendo uma interface que a aplicação espera utilizar

Padrão (Class)Adapter Estrutura e Participantes

Usando Herança Múltipla

Padrão (Class)Adapter Estrutura e Participantes

Usando Composição

Padrão Adapter Aplicabilidade

Use o Padrão Adapter quando: Você quer usar uma classe existente, e sua interface não é compatível com

uma que você necessita Você quer criar uma classe reusável que coopera com classes não-

relacionadas ou não previstas a priori, isto é, classes que não apresentam necessariamente interfaces compatíveis

(Somente para ObjectAdapter) Você precisa usar várias subclasses existentes (de Adaptee), mas é impraticável adaptar as interfaces de cada uma através de herança. Um ObjectAdapter pode resolver isto adaptando abstratamente a interface da superclasse.

Padrão Adapter Conseqüências

ClassAdapter Adapta uma classe concreta, mas NÃO SUAS SUBCLASSES Pode sobrepor alguns comportamentos do adaptado, visto que é uma

subclasse da classe adaptada ObjectAdapter

Permite que um único Adapter trabalhe com muitos adaptados. Ou seja, o próprio Adaptee e suas subclasses.

Pode adicionar funcionalidade extra a todos os adaptados de uma só vez. Dificulta a sobreposição do comportamento do adaptado.

Padrão Bridge(Handle, Body)

Padrão Bridge Intenção

Desacoplar uma abstração de sua implementação, de modo que as duas possam variar independentemente.

Também conhecido como Handle/Body

Motivação Quando uma abstração pode ter várias implementações a solução

usual é acomodar todas as implementações através de herança No entanto, herança liga de forma permanente uma abstração a

uma implementação O padrão Bridge permite colocar as abstrações e suas

implementações em diferentes hierarquias de classes, e permite que variem de forma independente

Padrão Bridge Estrutura e Participantes

Padrão Bridge Aplicabilidade

Use o Padrão Bridge Quando: Você quer evitar ligação permanente entre uma abstração e sua

implementação. Pode ser, por exemplo, quando se deseja variar a implementação em run-time

Tanto a abstração quanto a implementação devem ser extensíveis através de herança

Mudanças na implementação de uma abstração não devem ter impacto sobre o cliente

Padrão Bridge Conseqüências

Desacoplamento entre interface e implementação Implementação de uma abstração configurada em run-time Eliminação de dependências de compilação Criação de camadas de abstração que podem melhor estruturar o sistema

Extensibilidade incrementada Herança para abstração e implementação

Detalhes de implementação são escondidos do cliente

Padrão Decorator

Padrão Decorator Intenção

Anexa dinamicamente responsabilidades adicionais a um objeto. Provê uma alternativa flexível ao uso de herança como modo de estender funcionalidade.

Motivação Algumas vezes se quer adicionar responsabilidades a um objeto, mas não à sua

classe. Acontece, por exemplo, com a criação de interfaces gráficas, quando se deseja acrescentar uma borda a um componente qualquer ou um scrollbar a uma área de texto.

Uma forma de se acrescentar responsabilidades é através de herança, mas isto torna o projeto inflexível, pois a escolha da borda é definida em tempo de compilação. Neste caso o cliente não pode controlar como, onde e quando decorar o componente com uma borda.

Uma abordagem mais flexível é inserir o componente em outro objeto que adiciona a borda, um Decorator.

Padrão Decorator Estrutura e Participantes

Padrão Decorator Aplicabilidade

Use o padrão Decorator: Para adicionar responsabilidades a objetos individuais de forma dinâmica e

transparente, sem afetar outros objetos Para responsabilidades que podem ser removidas Quando extensão através de herança é impraticável. Algumas vezes uma

grande quantidade de extensões independentes são possíveis e seria necessário um imenso número de subclasses para suportar cada combinação possível entre elas.

Conseqüências Mais flexibilidade que herança Evita incorporação forçada de comportamentos desnecessários

Proxy

Padrão Proxy Intenção

Prover um representante para outro objeto de modo a controlar o acesso a este

Motivação Várias razões para controlar acesso a um objeto, como por

exemplo: deferir o custo de criação e inicialização para o momento de uso (objetos

sob demanda); Prover um representante local para um objeto remoto; Proteger o objeto original.

Padrão Proxy

Padrão Proxy Aplicabilidade

O Padrão Proxy é usado sempre que se precisa de uma referência a um objeto, que seja mais versátil ou sofisticada do que um simples ponteiro.

As principais situações são Remote Proxy - provê um representate local para um objeto em um espaço

de endereçamento diferente Virtual Proxy - cria objeto sob demanda Protection Proxy - controla acesso ao objeto original Smart References - executa operações adicionais quando o objeto é

acessado Contagem de referências, carga de objetos persistentes, locks

Copy-on-write - compartilhar grandes objetos, fazendo uma cópia apenas se necessário

Padrão Proxy Conseqüências

Acrescenta um nível de indireção adicional

Padrões GoF

Jobson Ronan {jrjsj@cin.ufpe.br}