Upload
rita-lancastre-balsemao
View
216
Download
2
Embed Size (px)
Citation preview
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
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 {[email protected]}