Padrões Estruturais - cic.unb.brjhcf/MyBooks/iess/Patterns/StructuralPatterns... · Flyweight -...

Padrões Estruturais

Padrões Estruturais de Design OO. Java Deployment Course. Copyright © 1999. Jorge H. C. Fernandes. [email protected]

Padrões Estruturais

� Tratam de compor classes e objetos para formar estruturas grandes e complexas

Adapter Composite

DecoratorFacade

FlyweightProxy

Bridge


Padrões Estruturais (1/2)

� Adapter - Adaptador (Classe) Converte a interface de uma classe em outra interface que clientes possam utilizar. Compatibiliza classes, permitindo que trabalhem em conjunto.

� Bridge - Ponte (Objeto) Desacopla uma abstração de sua implementação, de modo que as duas possam variar independentemente.

� Composite - Composição (Objeto) Compor objetos em estruturas de árvores para representar hierarquias parte-todo. Permitir que clientes tratem de modo uniforme objetos individuais e suas composições.


Padrões Estruturais (2/2)

� Decorator - Decorador (Objeto) Anexa dinamicamente responsabilidades adicionais a um objeto. Provê uma alternativa flexível ao uso de herança como modo de estender funcionalidade.

� Facade - Fachada (Objeto) Provê 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.

� Flyweight - Peso-mosca (Objeto) Usa compartilhamento para suportar um grande número de pequenos objetos de forma eficiente.

� Proxy - Representante (Objeto) Provê um ponto de atendimento para que outro objeto possa controlar o acesso ao primeiro.

Padrão Adapter (Wrapper)

Adapter


Padrão Adapter

� Intenção�Converter a interface de uma classe em outra interface que

clientes possam utilizar. Compatibiliza classes, permitindo que trabalhem em conjunto.

� Motivação�Algumas vezes uma classe (de um toolkit) não é reusável

somente 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 asespecificidades 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 AdapterAplicabilidade

� Use o Padrão Adapter quando:�Você quer usar uma classe existente, e sua interface não é

compatível com uma que você criou�Você quer criar uma classe reusável que cooperar com classes

não relacionadas ou não previstas a priori, isto é, classes que não apresentam necessariamente a mesma interface

�(Somente para ObjectAdapter) Você precisa usar várias subclasses existentes, mas é impraticável adaptar as interfaces de cada uma através de herança. Um ObjectAdapter pode resolver sito adaptando abstratamente a interface da superclasse


Padrão AdapterConseqüências

� ClassAdapter�Adapta uma classe concreta, mas NÃO SUAS SUBCLASSES�Pode suprepor alguns comportamentos do adaptado, visto que é

uma subclasse da classe adaptada�introduz apenas um objeto, sem maiores indireções

� ObjectAdapter�Permite que um único Adapter trabalhe com muitos adaptados

(e suas subclasses)�Pode adicionar funcionalidade extra a todos os adaptados de

uma vez só�Torna difícil sobrepor o comportamento do adaptado.


Padrão AdapterOutros Aspectos

� Quanta adaptação é necessária?� Adaptadores plugáveis� Adaptadores de mão dupla


Padrão AdapterExercícios

� Inclua um thread em um applet usando o padrão Adapter

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.

� 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 Colaboradores

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

�Você tem uma proliferação de classes, e quer evitá-las dividindo o objeto em duas partes

�Você que compartilhar uma implementação entre múltiplos objetos e este fato deve ser escondido do cliente.


Padrão BridgeConseqüências

� Desacoplamento entre interface e implementação�Implementação de uma abstração configurada em runtime�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 BridgeExercícios

� Acompanhe a execução de um programa Java que usa componentes visuais do AWT (um button por exemplo) e observe a divisão de tarefas entre a abstração (java.awt.Button) e a implementação do button(java.awt.peer.ButtonPeer)

Padrão Composite

Composite


Padrão Composite

� Intenção�Compor objetos em estruturas de árvores para representar

hierarquias parte-todo. Permitir que clientes tratem de modo uniforme objetos individuais e suas composições.

� Motivação�Aplicações gráficas como editores de programação visual

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

Componentoperation()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 parte-todo�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 (e

compostos)�Pode tornar o projeto excessivamente genérico


Padrão CompositeExercícios

� Examine a implementação das classes Component, Container e alguns componentes atômicos (Button, TextField, TextArea, Label, etc) do pacote java.awt�Monte a Hierarquia das Classes Examinadas�Identifique pelo menos 10 operações comuns a todos os

components�Identifique pelo menos 4 operações comuns aos Containers�Identifique algumas operações específicas de cada Component

atômico

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 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 e onde 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

Componentoperation()

ConcreteComponent

operation()

ConcreteDecoratorA

Operation()addedBehavior()

Decoratorcomponent

operation()

ConcreteDecoratorAOperation()

addedState

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

�Quando uma definição de classe pode estar escondida ou não disponível para herdar.

� Conseqüências�Mais flexibilidade que herança�Evita incorporação forçada de comportamentos desnecessários�Um decorador e seu componente não são idênticos!�Uma porção de objetos pequenos


Padrão DecoratorExercícios

� Veja o exemplo de código abaixo, que serializa um objeto e o armazena em um arquivo.

Class ContaBancaria implements Serializable {}...

FileInputStream in = new FileInputStream(”ContaBancaria.obj");ObjectInputStream s = new ObjectInputStream(in);ContaBancaria = (ContaBancaria) s.readObject();s.close();


Padrão DecoratorExercícios

� Observe o uso do padrão Decorator no subconjunto de classes abaixo, do pacote java.io�Perceba que as classes FilterInputStream (e suas subclasses) e

ObjectInputStream implementam o padrão Decorator sobre InputStream

Padrão Facade

Facade


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

Facadesubsistem classes

Client


Padrão FacadeAplicabilidade

�Use o Padrão Facade quando:�Você quer prover uma interface simplificada para um

subsistema complexo. Um Facade pode prover uma visão simples e default do subsistema, suficiente para a maioria dos clientes

�Existem muitas dependências entre clientes e classes da implementação. O Facade reduz esta dependência e promove independência e portabilidade

�Você quer criar sistemas em camadas. Um Facade provê o ponto de entrada para cada camada (nível) do subsistema.


Padrão FacadeConseqüências

�Protege os clientes dos componentes do subsistema

�Promove acoplamento fraco entre o subsistema e seus clientes�Reduz dependências de compilação, possivelmente

complexas ou circulares�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.


Padrão FlyweightEstrutura e Colaboradores (Cont...)

ConcreteFlyweight

Operation(extrinsincState)

FlyweightFactory

getFlyweight(key)

imp

If (flyweight[key] exists) {return existing flywieght

} else {create new flyweight;add it to pool of flyweights;return the new flyweight;

}

Client

UnsharedConcreteFlyweight


Flyweight


intrinsincState allState


Padrão FlyweightEstrutura e Colaboradores

Flyweight Pool

aConcreteFlyweight

intrinsincState

aConcreteFlyweight

intrinsincState

aFlyweightFactory

flyweights

aClient

extrinsincState()

aClient

extrinsincState


Padrão FlyweightAplicabilidade

� Use o Padrão Flyweight Quando TODAS as condições abaixo forem verdadeiras:�A aplicação usa uma grande quantidade de objetos�Custos de armazenamento são altos, por causa da imensa

quantidade de objetos�Parte considerável do estado do objeto pode ser tornar

extrínseco�uma vez que o estado extrínseco é removido, muitos

agrupamentos de objetos podem ser substituídos por uma quantidade consideravelmente menor de objetos compartilhados

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


Padrão FlyweightConseqüências

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

�Redução de consumo de memória é função de:�redução do número total de instâncias resultantes do

compartilhamento�quantidade de estado intrínseco por objeto�Se o estado extrínseco é armazenado ou computado


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 inicalizaçã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ã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


Padrão Proxy Conseqüências

�Acrescenta um nível de indireção adicional


Padrão Proxy Exercícios

�Identifique o padrão Proxy na API de rmi de Java

State

Memento Adapter Proxy

Bridge

Command

Chain of Responsibility

Singleton

Abstract Factory

Prototype

Template Method

Facade

Factory Method

Observer

MediatorStrategy

Decorator

Flyweight

Composite

Interpreter

Visitor

Iterator

Builder

Uma Linguagem de Padrões para Programas OO

AdicionandoOperações

AdicionandoOperações

EnumerandoFilhos

SalvandoEstado da Operação

CriandoComposições

AdicionandoResponsabilidades

a Objetos

Modificando Peleversus Entranhas

CompartilhandoComposições

DefinindoGramática

DefinindoTravessias

Definindoa Cadeia

CompostoUsando

EvitandoHisterese

CompartilhandoEstratégias

CompartilhandoEstados Compartilhando

Terminais

ConfigurarFábrica

Dinamicamente

ÚnicaInstância

ÚnicaInstância

ImplementadaUsando

GerenciamentoComplexo deDependências

Freqüentemente Usa

DefinindoPassos doAlgoritmo

Padrões Estruturais - cic.unb.brjhcf/MyBooks/iess/Patterns/StructuralPatterns... · Flyweight -...

Documents

Transcript of Padrões Estruturais - cic.unb.brjhcf/MyBooks/iess/Patterns/StructuralPatterns... · Flyweight -...