peter jandl jr dca/unicamp · flyweight, proxy. • padrões de comportamento (behavioral) –...

��

� � ��

Peter Jandl Jr

DCA/Unicamp

2002

11/21/02 Padrões de Projeto 2

� �� !� �� !�� • "Cada padrão descreve um problema que

ocorre outra e mais outra vez no nosso ambiente, e então descreve o âmago da solução deste problema, de forma que 'você possa usar esta solução um milhão de vezes, sem fazer o mesmo duas vezes." [1]

• "Um padrão de projeto sistematicamente nomeia, motiva e explica um projeto genérico, que endereça um problema de projeto recorrente em sistemas orientados a objetos. Ele descreve o problema, a solução, quando é aplicável e quais as consequências de seu uso." [3]


"�# $ %�& '( )#"# $ %�& '( )#

• O simples uso da OO não garante que obtenhamos sistemas confiáveis, robustos, extensíveis e reutilizáveis.

• O foco das metodologias de desenvolvimento está na solução em si (o que e como) e não em suas justificativas (porque).

• É difícil compartilhar a experiência entre experts e novatos.


*,+ -+ . /10 - 243 / 5 .+ 3*,+ -+ . / 0 - 243 / 5 .+ 3 67 8 69 8

• Descrever e justificar soluções para problemas concretos e bem definidos (não são estratégias de implementação);

• Ser comprovados, isto é, devem ter sido previamente experimentados e testados;

• Tratar problema que ocorram em diferentes contextos;


��

• Descrever relações entre conceitos, mecanismos e estruturas existentes nos sistemas, seus pontos fortes e fracos;

• Capturar a evolução e aprimoramento das soluções;

• Ser utilizados em conjunto com outros padrões, compondo linguagens de padrões.


��

• Permitem compartilhar experiências bem sucedidas na resolução de problemas recorrentes;

• Compõem um vocabulário de alto nível para discussão de questões relativas ao projeto de sistemas de software;

• Permitem que os desenvolvedores concentrem seus esforços nos aspectos inéditos do problema.


�� ! "$# %�� ! "$# %

&# � '( ) # &&# � '( )�# &+*, -

• Nome e Classificação

• Propósito

• Nome Secundário

• Motivação

• Aplicabilidade

• Estrutura

• Participantes

• Colaborações

• Consequências

• Implementação

• Exemplo

• Usos Conhecidos

• Padrões Relacionados


. /�0 12 3�4 5�6 387 9 1. / 0 12 3�4 5�6 387 9 1;:< =

• Padrões de Criação (Creational)– Abstract Factory, Builder, Factory Method,

Prototype, Singleton.

• Padrões de Estrutura (Structural)– Adapter, Bridge, Composite, Decorator, Facade,

Flyweight, Proxy.

• Padrões de Comportamento (Behavioral)– Chain of Responsability, Command, Interpreter,

Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor.


� ��

• Garante que para uma classe específica só possa existir uma única instância, a qual é acessível de forma global e uniforme.

• A classe Singleton deve:– armazenar a única instância existente;

– garante que apenas uma instância será criada;

– provê acesso a tal instância.


��

Singleton

static instance: Singleton

return instancestatic getInstance(): Singleton


� ��

// SingletonImpl.java

public final class SingletonImpl { private static SingletonImpl instance = null;

private SingletonImpl() { ... }

public SingletonImpl getInstance() { if (instance==null) { instance = new SingletonImpl(); } return instance; }}


� �� ! �� ! �

// UsoDoSingletonImpl.java

public class UsoDoSingletonImpl { : SingletonImpl obj; : obj = SingletonImpl.getInstance(); :}


��

• Provê uma forma de percorrermos os elementos de uma coleção sem violar o seu encapsulamento.

• Toda coleção possui uma representação interna para o armazenamento e organização de seus elementos .

• O Iterator mantém separadas as responsabilidades de navegação por tais elementos.


��

Collection

getIterator(): Iterator

ConcreteCollection

getIterator(): Iterator

Iterator

hasNext(): booleannext(): Object

ConcreteIterator

return new ConcreteIterator(this)


� ��

/ / I I t er at or . j ava

/ / i nt er f ace par a navegação de col eções quai squerpubl i c i nt er f ace I I t er at or { / / ver i f i ca a exi st ênci a de um pr óxi mo el ement o public boolean hasNext(); / / r et or na o pr óxi mo el ement o public Object next();}


��

/ / I Col ecao. j ava

/ / obt enção de I t er at or par a col eções

publ i c i nt er f ace I Col ecao {

/ / oper ação par a obt enção de um I t er at or

public IIterator getIterator();

}


��

// Lista.javapublic class Lista implements IColecao { private Object conteudo[]; public Lista() { this(10); } public Lista(int t) { conteudo=new Object[]; } private int indexOf(Object objeto) { ... } public boolean has(Object objeto) { ... } public boolean add(Object objeto) { ... } public Object remove(Object objeto) { ... } public void removeAll() { ... } public IIterator getIterator() { return new ListaIterator(this); } public class ListaIterator implements IIterator{}}


��

publ i c c l ass Li st aI t er at or i mpl ement s I I t er at or { pr i vat e Li st a l i s t a; / / r ef er ênci a par a Li st a pr i vat e i nt ul t i mo; / / cont r ol e de posi ção

publ i c Li st aI t er at or ( Li st a l i s t a) { t hi s. l i s t a = l i s t a; ul t i mo = - 1; }

public boolean hasNext() { ... } public Object next() { ... }

}


� ��

/ / UsoDaLi st a. j avapubl i c c l ass UsoDaLi st a { : Lista lista = new Lista(); // instancia Lista : l i s t a. add( obj 1) ; / / execut a oper ações l i s t a. r emove( obj 2) ; / / necessár i as : / / at r avés do I t er at or per cor r e l i s t a IIterator it = lista.getIterator(); while(it.hasNext()) { System.out.println(it.next()); } :}


��

• É uma interface para instanciação de objetos que mantém isoladas as classes concretas usadas da requisição da criação destes objetos.

• Separa assim:– uma “ família” de classes dotadas da mesma

interface (“produtos”); e

– uma classe (“ fábrica” ) que possui um método especial (o factory method) que cria tais objetos.


��

ConcreteFactory

Product

ConcreteProduct1

createProduct(): Product

Factory

createProduct(): Product

if (cond) return new ConcreteProduct1()else return new ConcreteProduct2()

ConcreteProduct2


��

• São comuns as situações onde temos que lidar com uma estrutura de elementos agrupada hierarquicamente (não como meras coleções).

• Composições podem cumprir com este requisito e ainda permitir:– o tratamento da composição como um todo;– ignorar as diferenças entre composições e

elementos individuais;– adição transparente de novos tipos a hierarquia;– simplificação do cliente.


�� !" # !$ %& '( )*

Container

operation1()operation2()addComponent(Component): voidremoveComponent(Component): voidgetComponent(int): ComponentgetComponentCount(): int

Component

operation1()operation2()getParent(): Component

children

ConcreteComponent

operation1()operation2()

Client uses


+ ,.- /0 1 / 0+ ,.- / 0 1 / 0

• Existem situações onde diversos objetos (p.e. visualizações) devem representar um outro objeto (p.e. dados).

• Define uma relação de dependência 1:N de forma que quando um certo objeto (assunto) tem seu estado modificado os demais (observadores) são notificados.

• Possibilita baixo acoplamento entre os objetos observadores e o assunto.


� ��

Observer

update(): void

ConcreteObserver

observerState: State

update(): void

Subject

atach(Observer): voiddetach(Observer): voidnotify(): void

ConcreteSubject

subjectState: State

get State(): StatesetState(State): void

observers

subject

return subjectState

for all obs in observers obs.update() observerState = subject.getState ()


��

• Associa uma ação a diferentes objetos através de uma interface conhecida.

• Permite que objetos deste tipos tenham tais ações executadas sem que conheçamos o tipo de tais objetos ou a natureza das ações.

• Possibilita:– isolar requisitante do executor;– registro (log) e/ou retrocesso (undo) de ações; e– execução em instante posterior a requisição

(permite enfileirar ações para processamento em outro momento).


��

Client

Invoker Command

execute(): void

Receiver

action(): voidConcreteCommand

state

execute(): void

receiver.action()

receiver


��

! �"#��$ % � & � � �� ! �"#��$ % � & � � ��

[1] ALEXANDER, C., ISHIKAWA, S., SILVERSTEIN, M., JACOBSON, M., FIKSDAHL-KING, I., ANGEL, S. "A Pattern Language". New York, NY (USA): Oxford University Press, 1977.

[2] COPLIEN, J. O. "Software Patterns". New York, NY (USA): SIGS Books, 1996.

[3] GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J. "Design Patterns: Elements of Reusable Object-Oriented Software". Reading, MA: Addison Wesley, 1995.

[4] GEARY, D. ”A look at the Composite pattern". IN JavaWorld, setembro, 2002. [ '( ()* + +, ,,.- /01 0 , 23 45- 6 27 + /01 0 , 23 4 5 + /,8 9 :8 ; 9 9 ; + /, 8 9 :< =8 5>? @AB ) 0 ( (> 3B?DC ) - '( 7 4 ].

peter jandl jr dca/unicamp · flyweight, proxy. • padrões de comportamento (behavioral) –...

Documents