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

Apresentação em tema: "Padrões Estruturais Tratam de compor classes e objetos para formar estruturas grandes e complexas."— Transcrição da apresentação:

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

2 Padrão Adapter (Wrapper) Adapter

3 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Adapter zIntenção yConverter a interface de uma classe em outra interface, esperada pelos clientes. Permite que classes com interfaces incompatíveis trabalhem em conjunto. zTambém conhecido como yWrapper zMotivação yAlgumas 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. yA solução é criar um objeto adaptador, que encapsule e filtre as especificidades da classe adaptada, fornecendo uma interface que a aplicação espera utilizar

4 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br specificRequest() Client Target request() Adapter request() Adaptee specificRequest() Padrão (Class)Adapter Estrutura e Participantes zUsando Herança Múltipla

5 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br adaptee.specificRequest(); Client Target request() Adapter request() Adaptee specificRequest() Padrão (Object)Adapter Estrutura e Participantes zUsando Composição adaptee

6 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Adapter Aplicabilidade zUse o Padrão Adapter quando: yVocê quer usar uma classe existente, e sua interface não é compatível com uma que você necessita yVocê 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 y(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.

7 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Adapter Conseqüências zClassAdapter yAdapta uma classe concreta, mas NÃO SUAS SUBCLASSES yPode sobrepor alguns comportamentos do adaptado, visto que é uma subclasse da classe adaptada zObjectAdapter yPermite que um único Adapter trabalhe com muitos adaptados. Ou seja, o próprio Adaptee e suas subclasses. yPode adicionar funcionalidade extra a todos os adaptados de uma só vez. yDificulta a sobreposição do comportamento do adaptado.

8 Padrão Bridge(Handle, Body) Bridge

9 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Bridge zIntenção yDesacoplar uma abstração de sua implementação, de modo que as duas possam variar independentemente. zTambém conhecido como yHandle/Body zMotivação yQuando uma abstração pode ter várias implementações a solução usual é acomodar todas as implementações através de herança yNo entanto, herança liga de forma permanente uma abstração a uma implementação yO padrão Bridge permite colocar as abstrações e suas implementações em diferentes hierarquias de classes, e permite que variem de forma independente

10 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Bridge Estrutura e Participantes Implementor operationImp() ConcreteImplementorA operationImp() ConcreteImplementorB operationImp() Abstraction operation() imp imp.operationImpl(); RefinedAbstraction Client

11 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Bridge Aplicabilidade zUse o Padrão Bridge Quando: yVocê 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 yTanto a abstração quanto a implementação devem ser extensíveis através de herança yMudanças na implementação de uma abstração não devem ter impacto sobre o cliente

12 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Bridge Conseqüências zDesacoplamento entre interface e implementação yImplementação de uma abstração configurada em run-time yEliminação de dependências de compilação yCriação de camadas de abstração que podem melhor estruturar o sistema zExtensibilidade incrementada yHerança para abstração e implementação zDetalhes de implementação são escondidos do cliente

13 Padrão Composite Composite

14 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Composite zIntenção yCompor objetos em estruturas de árvores para representar hierarquias todo-parte. Permitir que clientes tratem de modo uniforme objetos individuais e suas composições. zMotivação yAplicações gráficas como editores de desenhos permitem a construção de diagramas complexos a partir de componentes simples. yO usuário agrupa vários componentes, criando um agregado. yCaso haja separação entre componentes primitivos e agregados, criam-se dificuldades no tratamento uniforme da edição yA solução é criar uma classe abstrata que representa tanto os componentes primitivos como os agregados (containers)

15 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Composite Estrutura e Participantes Component operation() add(Component) remove(Component) getChild(int) getParent() Leaf operation() Composite Operation() add(Component) remove(Component) getChild(int) children Client

16 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Composite Aplicabilidade e Conseqüências zUse o Padrão Composite Quando: yvocê quer representar hierarquias de objeto todo-parte yVocê quer clientes aptos a ignorar as diferenças entre composições de objetos e objetos individuais. Clientes tratarão objetos de modo uniforme zConseqüências yDefinição de hierarquias de classes consistindo de objetos primitivos e compostos. Sempre que um cliente espera um objeto primitivo pode receber um objeto composto. yTorna o cliente simples yFacilita a criação de novas classes de componentes yPode tornar o projeto excessivamente genérico, tornando mais difícil restringir o comportamento dos componentes

17 Padrão Decorator Decorator

18 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Decorator zIntenção yAnexa dinamicamente responsabilidades adicionais a um objeto. Provê uma alternativa flexível ao uso de herança como modo de estender funcionalidade. zMotivação yAlgumas 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. yUma 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. yUma abordagem mais flexível é inserir o componente em outro objeto que adiciona a borda, um Decorator.

19 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Decorator Estrutura e Participantes Component operation() ConcreteComponent operation() ConcreteDecoratorB operation() addedBehavior() Decorator component operation() ConcreteDecoratorA operation() addedState Decorator::operation(); addedBehavior(); component.operation();

20 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Decorator Aplicabilidade zUse o padrão Decorator: yPara adicionar responsabilidades a objetos individuais de forma dinâmica e transparente, sem afetar outros objetos yPara responsabilidades que podem ser removidas yQuando 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. zConseqüências yMais flexibilidade que herança yEvita incorporação forçada de comportamentos desnecessários

21 Padrão Façade Façade

22 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Facade zIntenção yProver uma interface unificada para o conjunto de interfaces de um subsistema. Define uma interface de alto nível que faz um subsistema mais fácil de usar. zMotivação yEstruturar um sistema em subsistemas contribui para reduzir sua complexidade. A dependência entre subsistemas pode ser minimizada através do uso de um objeto Fachada, o qual provê uma interface única e uniforme para as diversas funcionalidades de um subsistema.

23 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Facade Estrutura e Participantes Façade subsystem classes Client

24 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Facade Aplicabilidade zUse o Padrão Façade quando: yVocê quer prover uma interface simplificada para um subsistema complexo. Um Façade pode prover uma visão simples do subsistema, suficiente para a maioria dos clientes yExistem muitas dependências entre clientes e classes da implementação. O Façade reduz esta dependência e promove independência e portabilidade yVocê quer criar sistemas em camadas. Um Façade provê o ponto de entrada para cada camada (nível) do subsistema.

25 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Façade Conseqüências zProtege os clientes dos componentes do subsistema zPromove acoplamento fraco entre o subsistema e seus clientes yReduz dependências de compilação yFacilita a portabilidade do sistema zNão evita que aplicações possam acessar diretamente as subclasses do sistema, se assim o desejarem.

26 Padrão Flyweight Flyweight

27 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Flyweight zIntenção yUsar compartilhamento para suportar uma grande quantidade de objetos de baixa granularidade de forma eficiente. zMotivação yAlgumas aplicações podem se beneficiar do uso de objetos em seu projeto, mas uma implementação ingênua pode tornar este uso proibitivamente dispendioso (principalmente o consumo de memória) yUm Flyweight é um objeto compartilhado que pode ser usado em múltiplos contextos simultaneamente, porque possui um estado intrínseco (comum a todos os contextos) e se utiliza de vários estados extrínsecos (particulares a cada contexto onde o Flyweight é usado). yClientes são responsáveis por passar o estado extrínseco ao Flyweight quando vão utilizá-lo.

28 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Flyweight Estrutura e Colaboradores ConcreteFlyweight Operation(extrinsincState) FlyweightFactory getFlyweight(key) imp If (flyweight[key] exists) { return existing flyweight } else { create new flyweight; add it to pool of flyweights; return the new flyweight; } Client UnsharedConcreteFlyweight Operation(extrinsincState) Flyweight Operation(extrinsincState) intrinsincStateallState

29 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Flyweight Aplicabilidade zUse o Padrão Flyweight quando TODAS as condições abaixo forem verdadeiras: yA aplicação usa uma grande quantidade de objetos yCustos de armazenamento são altos, por causa da imensa quantidade de objetos yParte considerável do estado do objeto pode se tornar extrínseco yUma vez que o estado extrínseco é removido, muitos agrupamentos de objetos podem ser substituídos por uma quantidade consideravelmente menor de objetos compartilhados yA aplicação não depende de identidade de objetos. Visto que flyweights podem ser compartilhados, testes de identidade irão retornar true para objetos conceitualmente distintos.

30 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Flyweight Conseqüências zCustos de run-time associados com transferência, busca e/ou computação do estado extrínseco. Tais custos são compensados pela economia em uso de memória, à medida que mais flyweights são criados. zRedução de consumo de memória é função de: yredução do número total de instâncias resultantes do compartilhamento yquantidade de estado intrínseco por objeto ySe o estado extrínseco é armazenado ou computado

31 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Proxy

32 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Proxy zIntenção yProver um representante para outro objeto de modo a controlar o acesso a este zMotivação yVárias razões para controlar acesso a um objeto, como por exemplo: xdeferir o custo de criação e inicialização para o momento de uso (objetos sob demanda); xProver um representante local para um objeto remoto; xProteger o objeto original.

33 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Proxy Estrutura e Colaboradores RealSubject request()... Client Proxy request()... Subject request() realSubject.request();

34 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Proxy Aplicabilidade zO 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. zAs principais situações são yRemote Proxy - provê um representate local para um objeto em um espaço de endereçamento diferente yVirtual Proxy - cria objeto sob demanda yProtection Proxy - controla acesso ao objeto original ySmart References - executa operações adicionais quando o objeto é acessado xContagem de referências, carga de objetos persistentes, locks yCopy-on-write - compartilhar grandes objetos, fazendo uma cópia apenas se necessário

35 Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. jhcf@di.ufpe.br Padrão Proxy Conseqüências zAcrescenta um nível de indireção adicional