Upload
matheus-henrique-rios-lage
View
212
Download
0
Embed Size (px)
Citation preview
Padrões Estruturais
Tratam de compor classes e objetos para formar estruturas grandes e complexas
Padrão Adapter (Wrapper)
Adapter
Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
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ões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
specificRequest()
Client Target
request()
Adapter
request()
Adaptee
specificRequest()
Padrão (Class)AdapterEstrutura e Participantes
Usando Herança Múltipla
Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
adaptee.specificRequest();
Client Target
request()
Adapter
request()
Adaptee
specificRequest()
Padrão (Object)AdapterEstrutura e Participantes
Usando Composição
adaptee
Padrão Bridge(Handle, Body)
Bridge
Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
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ões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
Padrão BridgeEstrutura e Participantes
Implementor
operationImp()
ConcreteImplementorA
operationImp()
ConcreteImplementorB
operationImp()
Abstraction
operation()
imp
imp.operationImpl();
RefinedAbstraction
Client
Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
Padrão BridgeAplicabilidade
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ões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
Padrão BridgeConseqüê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 Composite
Composite
Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
Padrão Composite Intenção
Compor objetos em estruturas de árvores para representar hierarquias todo-parte. Permitir que clientes tratem de modo uniforme objetos individuais e suas composições.
Motivação Aplicações gráficas como editores de desenhos permitem a
construção de diagramas complexos a partir de componentes simples.
O usuário agrupa vários componentes, criando um agregado. Caso haja separação entre componentes primitivos e
agregados, criam-se dificuldades no tratamento uniforme da edição
A solução é criar uma classe abstrata que representa tanto os componentes primitivos como os agregados (containers)
Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
Padrão CompositeEstrutura e Participantes
Component
operation()add(Component)remove(Component)getChild(int)getParent()
Leaf
operation()
Composite
Operation()add(Component)remove(Component)getChild(int)
children
Client
Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
Padrão CompositeAplicabilidade e Conseqüências
Use o Padrão Composite Quando: você quer representar hierarquias de objeto todo-parte Você quer clientes aptos a ignorar as diferenças entre
composições de objetos e objetos individuais. Clientes tratarão objetos de modo uniforme
Conseqüências Definição de hierarquias de classes consistindo de objetos
primitivos e compostos. Sempre que um cliente espera um objeto primitivo pode receber um objeto composto.
Torna o cliente simples Facilita a criação de novas classes de componentes Pode tornar o projeto excessivamente genérico, tornando
mais difícil restringir o comportamento dos componentes
Padrão Decorator
Decorator
Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
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ões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
Padrão DecoratorEstrutura e Participantes
Component
operation()
ConcreteComponent
operation()
ConcreteDecoratorB
operation()addedBehavior()
Decoratorcomponent
operation()
ConcreteDecoratorAoperation()
addedState
Decorator::operation();addedBehavior();
component.operation();
Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
Padrão DecoratorAplicabilidade
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
Padrão Façade
Façade
Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
Padrão Facade Intenção
Prover 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.
Motivação Estruturar 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.
Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
Padrão FacadeEstrutura e Participantes
Façadesubsystem classes
Client
Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
Padrão FacadeAplicabilidade
Use o Padrão Façade quando: Você 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
Existem muitas dependências entre clientes e classes da implementação. O Façade reduz esta dependência e promove independência e portabilidade
Você quer criar sistemas em camadas. Um Façade provê o ponto de entrada para cada camada (nível) do subsistema.
Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
Padrão FaçadeConseqüências
Protege os clientes dos componentes do subsistema
Promove acoplamento fraco entre o subsistema e seus clientes Reduz dependências de compilação Facilita a portabilidade do sistema
Não evita que aplicações possam acessar diretamente as subclasses do sistema, se assim o desejarem.
Padrão Flyweight
Flyweight
Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
Padrão Flyweight Intenção
Usar compartilhamento para suportar uma grande quantidade de objetos de baixa granularidade de forma eficiente.
Motivação Algumas 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)
Um 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).
Clientes são responsáveis por passar o estado extrínseco ao Flyweight quando vão utilizá-lo.
Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
Proxy
Proxy
Padrões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
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ões Estruturais de Design OO. Java Deployment Course. Recife, DI-UFPE, Maio de 1999. Jorge H. C. Fernandes. [email protected]
Padrão Proxy Estrutura e Colaboradores
RealSubject
request()...
Client
Proxy
request()...
Subject
request()
realSubject.request();