Padrões GoF

1. Padrões GoF Jobson Ronan {jrjsj@cin.ufpe.br}

2. Padrões Estruturais • Tratam de compor classes e objetos para formar estruturas grandes e complexas

3. Padrão Adapter (Wrapper)

4. 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

5. Padrão (Class)Adapter • Estrutura e Participantes • Usando Herança Múltipla

6. Padrão (Class)Adapter • Estrutura e Participantes • Usando Composição

7. 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.

8. 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.

9. Padrão Bridge(Handle, Body)

10. 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

11. Padrão Bridge • Estrutura e Participantes

12. 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

13. 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

14. Padrão Decorator

15. 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.

16. Padrão Decorator • Estrutura e Participantes

17. 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

18. Proxy

19. 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.

20. Padrão Proxy

21. 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

22. Padrão Proxy • Conseqüências • Acrescenta um nível de indireção adicional

23. Padrões GoF Jobson Ronan {jrjsj@cin.ufpe.br}