Padrões GoF
Jobson Ronan {[email protected]}
Padrões Estruturais

Tratam de compor classes e objetos para formar estruturas
grandes e complexas
Padrão Adapter (Wrapper)
Padrão Adapter

Intenção


Também conhecido como


Converter a interface de uma classe em outra interface, esperada
pelos clientes. Permite que classes com interfaces incompatíveis
trabalhem em conjunto.
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ãorelacionadas 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


Também conhecido como


Desacoplar uma abstração de sua implementação, de modo que
as duas possam variar independentemente.
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



Extensibilidade incrementada


Eliminação de dependências de compilação
Criação de camadas de abstração que podem melhor estruturar o sistema
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 {[email protected]}