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

Apresentação em tema: "Jobson Ronan {jrjsj@cin.ufpe.br} Padrões GoF Jobson Ronan {jrjsj@cin.ufpe.br}"— Transcrição da apresentação:

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

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 Também conhecido como Motivaçã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 ObjectAdapter
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 Também conhecido como Motivaçã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 Motivaçã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 Conseqüências 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 Motivaçã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 Jobson Ronan {jrjsj@cin.ufpe.br}
Padrões GoF Jobson Ronan