padrões estruturais tratam de compor classes e objetos para formar estruturas grandes e complexas

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


specificRequest()

Client Target

request()

Adapter

request()

Adaptee

specificRequest()

Padrão (Class)AdapterEstrutura e Participantes

Usando Herança Múltipla


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ã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 BridgeEstrutura e Participantes

Implementor

operationImp()

ConcreteImplementorA

operationImp()

ConcreteImplementorB

operationImp()

Abstraction

operation()

imp

imp.operationImpl();

RefinedAbstraction

Client


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ã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ã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ã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ã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ã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 DecoratorEstrutura e Participantes

Component

operation()

ConcreteComponent

operation()

ConcreteDecoratorB

operation()addedBehavior()

Decoratorcomponent

operation()

ConcreteDecoratorAoperation()

addedState

Decorator::operation();addedBehavior();

component.operation();


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ã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ão FacadeEstrutura e Participantes

Façadesubsystem classes

Client


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


Proxy

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 Estrutura e Colaboradores

RealSubject

request()...

Client

Proxy

request()...

Subject

request()

realSubject.request();

padrões estruturais tratam de compor classes e objetos para formar estruturas grandes e complexas

Documents