padrões de projeto de software -...

Luiz Leão – [email protected]

http://www.luizleao.com

Padrões de Projeto de Software

Unidade 2 – Padrões GoF

mailto:[email protected]

http://www.luizleao.com/


Padrões de Projetos de Software

Conteúdo Programático

• PADRÕES CRIAÇÃO

– Abstract Factory

– Builder

– Factory Method

– Prototype

– Singleton.

• PADRÕES

ESTRUTURAIS

– Adapter

– Bridge

– Composite

– Decorator

– Façade

– Flyweight

– Proxy

• PADRÕES

COMPORTAMENTAIS

– Chain of

Responsibility

– Command

– Interpreter

– Iterator

– Mediator

– Memento

– Observer

– State

– Strategy

– Template Method

– Visitor



Catálogo de Padrões (GoF)

• Um padrão encerra o conhecimento de uma pessoa muito

experiente em um determinado assunto de uma forma

que este conhecimento pode ser transmitido para outras

pessoas menos experientes.

• Outras ciências (p.ex. química) e engenharias possuem

catálogos de soluções.

• Desde 1995, o desenvolvimento de software passou a ter

o seu primeiro catálogo de soluções para projeto de

software: o livro do GoF (Gang of Four).




• E. Gamma and R. Helm and

R. Johnson and J. Vlissides.

Design Patterns 5 - Elements

of Reusable Object-Oriented

Software. Addison-Wesley,

1995.




• Passamos a ter um vocabulário comum para conversar

sobre projetos de software.

• Soluções que não tinham nome passam a ter nome.

• Ao invés de discutirmos um sistema em termos de pilhas,

filas, árvores, passamos a falar de 6 coisas de muito mais

alto nível como Fábricas, Fachadas, Observador,

Estratégia, etc.




• A maioria dos autores eram entusiastas de Smalltalk,

principalmente o Ralph Johnson.

• Mas acabaram baseando o livro em C++ para que o

impacto junto à comunidade de C fosse maior.

• E o impacto foi enorme, o livro vendeu centenas de

milhares de cópias.




• PADRÕES CRIAÇÃO

– Abstract Factory

– Builder

– Factory Method

– Prototype

– Singleton.

• PADRÕES ESTRUTURAIS

– Adapter

– Bridge

– Composite

– Decorator

– Façade

– Flyweight

– Proxy

• PADRÕES

COMPORTAMENTAIS

– Chain of Responsibility

– Command

– Interpreter

– Iterator

– Mediator

– Memento

– Observer

– State

– Strategy

– Template Method

– Visitor



Classificação, segundo GoF



Classificação, segundo Metsker




• Encontrando objetos apropriados: a decomposição é influenciada

por fatores tais como encapsulamento, granularidade,

dependências, flexibilidade, desempenho, evolução, reutilização,

etc. Frequentemente surgem classes que não possuem

correspondentes no negócio

• Determinando a granularidade do objeto

• Especificando as interfaces dos objetos: um tipo denota uma

interface em particular. Um objeto pode ter muitos tipos e

diferentes objetos podem ter um mesmo tipo. Ligação dinâmica e

polimorfismo

Como os padrões resolvem os problemas?




• Especificando a implementação de objetos:

– Notação para classe.

– Instanciação (seta tracejada).

– Herança de classe (implementação).

– Classes abstratas (em itálico).

– Classes mix-in.

– Diferença entre a classe (implementação) e o tipo (interface) do

objeto

Como os padrões resolvem os problemas?




• Todo padrão inclui o mínimo:

– Nome

– Problema

– Solução

– Consequências

– Exemplo



Formato dos Padrões (GoF)

• Nome (inclui número da página): Um bom nome é

essencial para que o padrão tenha aceitação da

comunidade

• Objetivo / Intenção

• Motivação: Um cenário realista mostrando o problema e

a necessidade da solução

• Aplicabilidade: Como reconhecer as situações nas

quais o padrão é aplicável




• Estrutura: Uma representação gráfica da estrutura de

classes do padrão (usando OMT91) em, às vezes,

diagramas de interação (Booch 94)

• Participantes: As classes e objetos que participam e

quais são suas responsabilidades

• Colaborações: Como os participantes colaboram para

exercer as suas responsabilidades




• Conseqüências: Vantagens e desvantagens, trade-offs

• Implementação: Com quais detalhes devemos nos

preocupar quando implementamos o padrão, entre eles,

aspectos específicos de cada linguagem

• Exemplo de Código: No caso do GoF, em C++ (a

maioria) ou Smalltalk. Implementaremos em Java




• Usos Conhecidos: Exemplos de sistemas reais de

domínios diferentes onde o padrão é utilizado

• Padrões Relacionados: Quais outros padrões devem ser

usados em conjunto com esse quais padrões são

similares a este, quais são as diferenças




• Alguns padrões são utilizados em conjunto.

Ex: Composite com Iterator ou Visitor

• Alguns outros são alternativos.

Ex: Prototype ou Abstract Factory

• Alguns padrões apresentam projeto similar, embora

tenham diferentes propósitos.

Ex: Composite e Decorator

Exemplo:



Tipos de Padrões de Projeto

• Padrões de Criação: Estão relacionados com a forma

que os objetos são criados

• Padrões Estruturais: Tratam das associações entre

classes e objetos

• Padrões Comportamentais: Tratam das interações e

divisões de responsabilidades entre as classes ou

objetos.

Padrões de Criação




• Os padrões de criação tem como intenção

principal abstrair o processo de criação de

objetos, ou seja, a sua instanciação.

• Desta maneira o sistema não precisa se

preocupar com questões sobre, como o objeto é

criado, como é composto, qual a sua

representação real.




• Quando se diz que o sistema não precisa se

preocupar com a instanciação do objeto quer

dizer que, se ocorrer alguma mudança neste

ponto, o sistema em geral não será afetado.

• Isso é a famosa flexibilidade que os padrões de

projeto buscam.




• Padrões de criação com escopo de classe vão

utilizar herança para garantir que a flexibilidade.

Por exemplo, o padrão Factory Method pode

criar várias subclasses para criar o produto.

• Já os padrões com escopo de Objeto, como o

Prototype, delegam para um objeto (no caso o

protótipo) a responsabilidade de instanciar novos

objetos.




• Abstract Factory

• Builder

• Factory Method

• Prototype

• Singleton.



Abstract Factory

• Intenção:

– Prover uma interface para criação de famílias

de objetos relacionados sem especificar sua

classe concreta.



Abstract Factory

• Motivação: – Considere uma aplicação com interface gráfica que é

implementada para plataformas diferentes (Motif para UNIX e

outros ambientes para Windows e MacOS).

– As classes implementando os elementos gráficos não podem ser

definidas estaticamente no código. Precisamos de um

implementação diferente para cada ambiente. Até em um mesmo

ambiente, gostaríamos de dar a opção ao usuário de implementa

diferentes aparências (look-and-feels).



Abstract Factory

• Motivação (Cont.): – Podemos solucionar este problema definindo uma classe abstrata

para cada elemento gráfico e utilizando diferentes

implementações para cada aparência ou para cada ambiente.

– Ao invés de criarmos as classes concretas com o operador new,

utilizamos uma Fábrica Abstrata para criar os objetos em tempo

de execução.

– O código cliente não sabe qual classe concreta utilizamos.



Abstract Factory

• Aplicabilidade: Pode ser usado quando: – Um sistema deve ser independente da forma como

seus produtos são criados e representados;

– Um sistema deve poder lidar com uma família de

vários produtos diferentes;

– Você quer prover uma biblioteca de classes de

produtos mas não quer revelar as suas

implementações, quer revelar apenas suas interfaces.



Abstract Factory – Estrutura



Abstract Factory – Participantes

• AbstractFactory (WidgetFactory)

• ConcreteFactory (MotifWidgetFactory, WindowsWidgetFactory)

• AbstractProduct (Window, ScrollBar)

• ConcreteProduct (MotifWindow, MotifScrollBar, WindowsWindow,

WindowsScrollBar)

• Client - Usa apenas as interfaces declaradas pela

AbstractFactory e pelas classes AbstratProduct



Abstract Factory – Colaborações

• Normalmente, apenas uma instância de ConcreteFactory é criada em tempo de execução.

• Esta instância cria objetos através das classes ConcreteProduct correspondentes a uma família de

produtos.

• Uma AbstractFactory deixa a criação de objetos para

as suas subclasses ConcreteFactory.



Abstract Factory – Consequências

• Isola as classes concretas dos clientes;

• Facilita a troca de famílias de produtos (basta trocar

uma linha do código pois a criação da fábrica concreta

aparece em um único ponto do programa);

• Promove a consistência de produtos (não há o perigo

de misturar objetos de famílias diferentes);

• Dificulta a criação de novos produtos

• Ligeiramente diferentes (pois temos que modificar a

fábrica abstrata e todas as fábricas concretas).



Abstract Factory – Implementação

• Fábricas abstratas em geral são implementadas como

Singleton.

• Na fábrica abstrata, cria-se um método fábrica para cada

tipo de produto.

• Cada fábrica concreta implementa o código que cria os

objetos de fato.




• Se tivermos muitas famílias de produtos, teríamos um

excesso de classes "fábricas concretas".

• Para resolver este problema, podemos usar o Prototype:

criamos um dicionário mapeando tipos de produtos em

instâncias prototípicas destes produtos.

• Então, sempre que precisarmos criar um novo produto

pedimos à sua instância prototípica que crie um clone

(usando um método como clone() ou copy()).




• Em linguagens dinâmicas como Smalltalk onde classes

são objetos de primeira classe, não precisamos guardar

uma instância prototípica, guardamos uma referência

para a própria classe e daí utilizamos o método new para

construir as novas instâncias.



Abstract Factory – Usos Conhecidos

• InterViews: Usa fábricas abstratas para encapsular diferentes tipos

de aparências para sua interface gráfica

• ET++: Usa fábricas abstratas para permitir a fácil portabilidade para

diferentes ambientes de janelas (XWindows e SunView, por exemplo)

• Sistema de captura e reprodução de vídeo feito na UIUC usa fábricas

abstratas para permitir portabilidade entre diferentes placas de

captura de vídeo.

• Em linguagens dinâmicas como Smalltalk (e talvez em POO em

geral) classes podem ser vistas como fábricas de objetos.



Abstract Factory – Exemplo



Abstract Factory – Código

• WidgetFactory.java

abstract class WidgetFactory {

public static WidgetFactory obterFactory() {

if(Configuracao.obterInterfaceGraficaAtual() == Configuracao.MotifWidget) {

return new MotifWidgetFactory();

} else {

return new QtWidgetFactory();

}

}

public abstract Botao criarBotao();

}




• MotifWidgetFactory.java

class MotifWidgetFactory extends WidgetFactory {

public Botao criarBotao() {

return new BotaoMotif();

}

}




• QtWidgetFactory.java

class QtWidgetFactory extends WidgetFactory {

public Botao criarBotao() {

return new BotaoQt();

}

}




• Botao.java

abstract class Botao {

public abstract void desenhar();

}




• BotaoMotif.java

class BotaoMotif extends Botao {

public void desenhar(){

System.out.println("Eu sou um botao Motif!");

}

}




• BotaoQt.java

class BotaoQt extends Botao {

public void desenhar(){

System.out.println("Eu sou um botao Qt!");

}

}




• Client.java (Classe Executável)

public class Cliente {

public static void main(String[] args) {

WidgetFactory factory = WidgetFactory.obterFactory();

Botao botao = factory.criarBotao();

botao.desenhar();

}

}



Abstract Factory – Padrões Relacionados

• Factory Method

• Prototype

• Singleton



Factory Method

• Intenção:

– Definir uma interface (ou classe abstrata) para a criar

um objeto;

– Permitir a decisão de que implementações ou

subclasses devem ser instanciadas;

– Deixa uma classe deferir instanciação para subclasses

– Factory Method é conhecido como Virtual Constructor;



Factory Method

• Motivação:

– Os frameworks usam classes abstratas para

definir e manter relacionamentos entre objetos;

• Considere um framework para

aplicações que podem apresentar

múltiplos documentos pra usuários;

• Duas abstrações chaves: – Application (aplicação) e Document (documento);



Factory Method

• Problema: – A classe Application não pode prever a subclasse de

Document a ser instanciada;

• Ou seja, ela não tem conhecimento sobre o

tipo do Document apenas sabe quando deve

ser criado;



Factory Method

• Solução: – Usar o Factory Method que encapsula o conhecimento sobre a

subclasse de Document que deve ser criado movendo este

conhecimento para fora do framework;



Factory Method



Factory Method – Aplicabilidade

• Usar o padrão quando:

– Quando uma classe não pode antecipar ou conhecer a

classe dos objetos que deve criar;

– Quando uma classe quer que suas subclasses

especifiquem os objetos que criam;

– Quando classes delegam responsabilidade à alguma

das várias subclasses ajudantes, e deseja-se localizar

qual é a subclasse ajudante acessada.



Factory Method – Estrutura



Factory Method

• Colaborações para projeto:

– Uso da classe Creator que utiliza subclasses

para definir o seu método FactoryMethod

(método de fabricação) de maneira que retorne

um objeto ou instância do ConcretProduct

apropriado;



Factory Method – Consequências

• Vantagens:

– Elimina a necessidade de acoplar classes específicas para

aplicação em nível de código;

– Na programação, se lida apenas com a interface Product para

conhecer os métodos e atributos de uma forma genérica, o que

permite manipular as subclasses ou implementações de maneira

particular (ConcreteProduct).

– Fornece ganchos para classes

• Cria objetos através do método FactoryMethod

(métodos de fabricação);

• FactoryMethod possibilita as subclasses um gancho

para fornecer um versão estendida de um objeto;




• Vantagens:

– Conecta hierarquias de classes paralelas

• Ocorrem quando uma classe delega alguma das

suas responsabilidades para uma classe separada;




• Desvantagens:

– Os clientes podem ter que fornecer subclasses da classe Creator

somente para criar um objeto ConcreteProduct em particular;




• Implementação (dicas) :

– Duas principais variações do padrão Factory Method:

• O Creator é uma classe abstrata e não fornece uma

implementação para método de fabricação (factory

method) que ela declara;

• O Creator é uma classe concreta e fornece uma

implementação por omissão para o método de

fabricação (factory method);




• Implementação (dicas) :

– Método de fabricação (factory method) parametrizados:

• O método de fabricação recebe um parâmetro que

identifica o objeto a ser criado;



Factory Method – Exemplo



Factory Method – Código

• Aplicacao.java

abstract class Aplicacao {

private Documento doc;

//Abstração do Factory Method

abstract Documento criaDocumento();

void novoDocumento() {

this.doc = this.criaDocumento();

}

void abrirDocumento() {

this.doc.abrir();

}

}




• MinhaAplicacao.java

class MinhaAplicacao extends Aplicacao {

/**

* Uma implementação do Factory Method. Este método é

* especializado na criação de documentos do tipo

* MeuDocumento

*/

@Override

Documento criaDocumento() {

return new MeuDocumento();

}

}




• Documento.java

abstract class Documento {

void abrir() {

System.out.println("Documento:Abrir documento!");

}

void fechar() {

System.out.println("Documento:Fechar documento!");

}

void gravar() {

System.out.println("Documento:Gravar documento!");

}

}




• MeuDocumento.java

class MeuDocumento extends Documento {

private String word = "Word";

private String excel = "Excel";

String getWord() {

return this.word;

}

String getExcel() {

return this.excel;

}

}




• FactoyMethodTest.java

public class FactoyMethodTest {


MinhaAplicacao aplicacao = new MinhaAplicacao();

Documento docu = aplicacao.criaDocumento();

docu.abrir();

MeuDocumento documento = new MeuDocumento();

System.out.println("Documento: " + documento.getWord());

}

}



Factory Method – Padrões Relacionados

• Abstract Factory

• Template Method

• Prototype




• Análise do código:

– O que podemos melhorar e há alguma coisa errada com código?

– Falta alguma classe ser implementada?



Factory Method – Exercício

1. Implemente a aplicação mostrada na figura abaixo

usando Factory Method para criar os objetos.

1. Crie um objeto construtor para cada tipo de objeto (XXXFactory

para criar figuras do tipo XXX)

2. Utilize a fachada Figura, onde os construtores são guardados, e

um método estático que seleciona o construtor desejado com

uma chave.



Singleton



Singleton

• Intenção:

– Garantir que uma classe tenha somente uma

instância e fornecer um ponto global de acesso

para a mesma;



Singleton

• Motivação:

– Em muitas aplicações necessitamos garantir a

ocorrência de apenas uma instância de classes, pois

tais objetos podem fazer uso de recursos cuja

utilização deve ser exclusiva, ou porque se deseja que

os demais elementos do sistema compartilhem um

único objeto particular.

Ex.: Um filtro digital terá somente um conversor A/D;

Um sistema de contabilidades será dedicado somente

a uma companhia;



Singleton

• Problema: – Como garantir que uma classe tenha somente

um instância e que essa instância seja

facilmente acessível?

– Uma variável global torna um objeto acessível,

mas não impede você de instanciar múltiplos

objetos;



Singleton

• Solução:

– Tornar a própria classe responsável por

manter o controle da sua única instancia;

– A classe pode garantir que nenhuma outra

instância seja criada e fornecer um meio para

acessar sua única instância;

– Padrão Singleton;



Singleton – Aplicabilidade

• Usar o padrão quando:

– Deve haver uma única instância de uma classe

e esta deve ser acessada a partir de um ponto

de acesso bem conhecido.

– A instância única deve ser extensível através

de subclasses, possibilitando aos clientes usar

instância estendida sem alterar o seu código;



Singleton – Estrutura



Singleton

• Colaborações para projeto:

– Os clientes acessam uma instância Singleton

unicamente pela operação Instance do

Singleton;



Singleton – Consequências

• Vantagens:

– Acesso controlado à instância única;

– O Singleton tem controle sobre como e quando

clientes acessam a instância;

– Espaço de nomes reduzido;

• O Singleton é melhor que variáveis globais, já que

as “globais” podem ser encapsuladas na instância

única, deixando um único nome externo visível;



Singleton – Consequências

• Vantagens:

– Permite refinamento de operações e de

representação;

• Várias classes Singleton (relacionadas ou não via

herança) podem obedecer a mesma interface,

permitindo que um Singleton particular seja

escolhido para trabalhar com uma determinada

aplicação em tempo de execução;

– Mais flexível que métodos estáticos;



Singleton – Implementação (Dicas)

• Garantir uma única instância;

– Ocultando a operação que cria a instância usando um

operação de classe (isto é, uma função-membro

estática ou um método de classe);

• Criar subclasses da classe Singleton;

– A variável que referencia a instância do Singleton deve

ser iniciada com uma instância da subclasse;

• Retira-se a implementação da Instance da

classe-mãe e colocá-la na subclasse;




• Singleton.java public class Singleton {

private static Singleton instance = new Singleton();

int x;

String msg;

private Singleton() {

this.x = (int) (10 * Math.random());

this.msg = "-- A classe foi instanciada criando um Objeto

Singleton.\n" +

"\t # x inicializado com o valor inteiro: " + String.valueOf(this.x);

System.out.println(this.msg);

}

public static synchronized Singleton getInstance() {

if (instance == null)

instance = new Singleton();

return instance;

}

}




• SingletonTest.java

public class SingletonTest {

public static void main(String args[]) {

Singleton concreteSing = null;

concreteSing = concreteSing.getInstance();

}

}



Builder



Builder

• Intenção:

– Propõe que o processo de construção de um objeto, quando

complexo, seja separado da definição do objeto, para que

possamos ter diferentes algoritmos de construção permitindo

diferentes representações para o objeto.

– Devemos lembrar desde já que Factory Method e Abstract Factory

são padrões que trabalham na criação de objetos de uma família

de classes, trabalhando intensamente com polimorfismo,

enquanto o Builder tem o foco nos detalhes de construção de uma

instância de objeto, que não necessariamente terá uma família de

subclasses.



Builder – Estrutura

• Builder - Especifica a interface para criação de um objeto produto.

• ConcreteBuilder - São as implementações de Builder.

• Director - Classe que sabe o algoritmo de construção do objeto.

• Product - Representa o objeto-produto final.



Builder – Antipattern

• O que é?

– É um padrão de projeto de software que pode ser

comumente usado mas é ineficiente e/ou contra-

produtivo em prática



Builder – Antipattern

• Imaginemos uma situação onde precisamos construir

diferentes tipos de computadores com diferentes

componentes: servidor, computador para games e

computador básico.

• Poderíamos criar métodos em classes aleatórias que

criam os computadores porém as diferentes lógicas de

criação do computador ficariam espalhadas pelo código.

• O padrão Builder visa organizar justamente os processos

de criação de objetos complexos.



Builder – Aplicação

class builder2

ComputadorBasicoBuilder

+ createComputador() : void

+ addPlacaMae() : void

+ addHardDisks() : void

ComputadorBuilder

# computador: Computador




+ getComputador() : Computador

ComputadorDirector

~ builder: ComputadorBuilder

+ ComputadorDirector(ComputadorBuilder)

+ buildComputador() : Computador

ComputadorGamesBuilder




Serv idorBuilder




~builder



Builder – Exemplo

• Conversor de Texto:



Builder – Exemplo

• Conversor de Texto:

– Neste exemplo, o método lerRTF() (classe LeitorRTF) percorre uma lista

com os tokens encontrados no texto de entrada (formato RTF) e, para

cada tipo de token, chama um método do objeto de tipoConversorTexto.

– Dependendo do formato escolhido para o texto de destino, será escolhida

uma implementação da

classe ConversorTexto: ConversorPDF, ConversorTeX ou ConversorASC

II.

– Cada uma destas classes implementa os métodos de acordo com as

características do formato relacionado.

– A classe ConversorASCII não implementa os

métodos converteParagrafo() e converteFonte() pois este formato (ASCII)

não possui elementos de estilo.



Builder – Código

• ConversorTexto.java

abstract class ConversorTexto {

void converterCaractere(char c) {}

void converterParagrafo() {}

void converterFonte(Fonte f) {}

}



Builder – Código

• ConversorPDF.java

class ConversorPDF extends ConversorTexto {

void converterCaractere(char c) {

System.out.println("Caractere PDF");

}

void converterParagrafo() {

System.out.println("Paragrafo PDF");

}

void converterFonte(Fonte f) {

System.out.println("Fonte PDF");

}

}



Builder – Código

• ConversorTeX.java

class ConversorTeX extends ConversorTexto {


System.out.println("Caractere TeX");

}

void converterParagrafo() {

System.out.println("Paragrafo TeX");

}

void converterFonte(Fonte f) {

System.out.println("Fonte TeX");

}

}



Builder – Código

• ConversorASCII.java

class ConversorASCII extends ConversorTexto {


System.out.println("Caractere ASCII");

}

}



Builder – Código

• LeitorRTF.java class LeitorRTF {

private ConversorTexto conversor;

LeitorRTF(ConversorTexto c) {

this.conversor = c;

}

public void lerRTF() {

List<Token> tokens = obterTokensDoTexto();

for (Token t : tokens) {

if (t.getTipo() == Token.Tipo.CARACTERE){

conversor.converterCaractere(t.getCaractere());

}

if (t.getTipo() == Token.Tipo.PARAGRAFO) {

conversor.converterParagrafo();

}

if (t.getTipo() == Token.Tipo.FONTE) {

conversor.converterFonte(t.getFonte());

}

}

}

}



Builder – Código

• Cliente.java public class Cliente {


ConversorTexto conversor;

if (args[0].equals("pdf")) {

conversor = new ConversorPDF();

} else if (args[0].equals("tex")) {

conversor = new ConversorTeX();

} else {

conversor = new ConversorASCII();

}

LeitorRTF leitor = new LeitorRTF(conversor);

leitor.lerRTF();

}

}



Prototype

• Apresentação:

– Especifica os tipos de objetos a criar usando

uma instância de protótipo, criando-os

mediante cópia (ou clonagem) deste protótipo.

– Esta operação é realizada sem que a

aplicação saiba qual classe específica está

sendo instanciada.



Prototype

• Aplicabilidade:

– Em situações nas quais deve-se criar

instâncias de objetos a partir de hierarquias de

classes complexas e quando a classe de um

objeto é conhecida somente em tempo de

execução são exemplos do uso deste padrão

de projeto.



Prototype

• Estrutura:



Prototype

• Estrutura:

– Prototype: Uma classe que declara uma interface

para objetos capazes de clonar a si mesmo.

– PrototypeConcreto(1,2,...): Implementação de um

prototype;

– Cliente: Cria um novo objeto através de um prototype

que é capaz de clonar a si mesmo.



Prototype

• Descrição:

– A utilização deste padrão de projeto dá-se pela

existência de uma classe base (ou interface)

contendo a declaração do método clone() e,

dependendo da implementação, mantém um

coleção (na forma de um dicionário, por

exemplo) de classes concretas derivadas da

classe base (ou que implementem a interface).



Prototype

• Exemplo na API Java:

– Este padrão de projeto é a essência da

especificação JavaBean. A interface java.lang.Cloneable existe para que

classes a implementem, e, assim, atestem que

podem ser clonadas, mediante a sobre-escrita do método clone(), disponível na classe

java.lang.Object.



Prototype

• Observações:

– Eventualmente, padrões de projeto de criação

competem entre si em uso.

– Às vezes pode-se utilizar ou o padrão de

projeto Prototype ou Abstract Factory.

– Enquanto em outros casos, ambos são

complementos um do outro.



Prototype

• Padrões Relacionados

– Abstract Factory, Composite e Decorator.



Prototype

• Anti-Pattern

– O uso deste padrão de projeto destina-se a criar

cópias (clones) a partir de uma instância denominada

protótipo.

– Assim, o seu anti-pattern é a situação na qual toda vez

que uma cópia de um determinado objeto é necessária

sua criação deve ser realizada, comprometendo,

possivelmente, o desempenho da aplicação e a

quantidade de memória para comportar um número

elevado de objetos.



Prototype

• Exemplo:

– Neste exemplo é mostrado uma hierarquia de classes

representando documentos de

formato ASCII e PDF que são criados através da classe Cliente.

– A partir de duas instâncias prototípicas, ascii e pdf,

o método criarDocumento cria clones de

documentos de acordo com o tipo desejado.

– A tarefa de realizar a criação da instância é

implementada na classe Documento e herdada por

suas classes filhas, ASCII ePDF.



Prototype

• Exemplo:



Prototype - Código

• Icloneable.java:

public interface ICloneable {

public void clone();

}



Prototype - Código

• Documento.java:

abstract class Documento implements ICloneable {

protected Documento clone() {

Object clone = null;

try {

clone = super.clone();

} catch (CloneNotSupportedException ex) {

ex.printStackTrace();

}

return (Documento) clone;

}

}



Prototype - Código

• ASCII.java:

class ASCII extends Documento {

}



Prototype - Código

• PDF.java:

class PDF extends Documento {

}



Prototype - Código

• Cliente.java:

class Cliente {

static final int DOCUMENTO_TIPO_ASCII = 0;

static final int DOCUMENTO_TIPO_PDF = 1;

private Documento ascii = new ASCII();

private Documento pdf = new PDF();

public Documento criarDocumento(int tipo) {

if (tipo == Cliente.DOCUMENTO_TIPO_ASCII) {

return ascii.clone();

} else {

return pdf.clone();

}

}

}

Padrões Estruturais




• Os padrões estruturais vão se preocupar em como as

classes e objetos são compostos, ou seja, como é a sua

estrutura.

• O objetivo destes padrões e facilitar o design do sistema

identificando maneiras de realizar o relacionamento entre

as entidades, deixando o desenvolvedor livre desta

preocupação.




• Os padrões com escopo de classe utilizam a herança

para compor implementações ou interfaces.

• O padrão Adapter, por exemplo, pode definir uma nova

interface para adaptar duas outras já existentes, assim

uma nova classe é criada para adaptar uma interface a

outra. Os padrões com escopo de objeto utilizam a

composição de objetos para definir uma estrutura.

• Por exemplo, o padrão Composite define

(explicitamente) uma estrutura de hierárquica para

classes primitivas e compostas em um objeto.




• Adapter

• Bridge

• Composite

• Decorator

• Façade

• Flyweight

• Proxy

Padrões Comportamentais




• Os padrões comportamentais atuam sobre como

responsabilidades são atribuídas as entidades, ou seja,

qual o comportamento das entidades.

• Estes padrões facilitam a comunicação entre os objetos,

distribuindo as responsabilidades e definindo a

comunicação interna.




• Padrões com escopo de classe utilizam herança para

realizar a distribuição do comportamento.

• Um bom exemplo é o padrão Template Method, que

fornece um algoritmo (comportamento) padrão e deixa as

subclasses definirem alguns pontos da execução do

algoritmo.

• Já os padrões de objetos vão compor os objetos para

definir a comunicação, como o padrão Mediator, que

define um objeto que realiza a comunicação muitos-para-

muitos.




• Chain of Responsibility

• Command

• Interpreter

• Iterator

• Mediator

• Memento

• Observer

• State

• Strategy

• Template Method

• Visitor



Chain of Responsibility




• Apresentação:

• Normalmente, este padrão de projeto é utilizado em

situações nas quais se deseja que mais de um objeto

possa tratar (manipular) um pedido (requisição), evitando

o acoplamento entre o remetente de um pedido e o seu

destinatário.

• Assim, os objetos recebedores são encadeados e o

pedido é passado por este encadeamento até que um

objeto o trate.




• Aplicabilidade:

• Este padrão de projeto é comumente utilizando quando

mais de um objeto é capaz de tratar um pedido e o mesmo

não é conhecido antecipadamente.

• O objeto tratador do pedido deve ser reconhecido

automaticamente.

• Um pedido deve ser tratado por um entre vários objetos

sem que o objeto tratador seja especificado explicitamente.




• Estrutura:




• Estrutura:

• Cada objeto no encadeamento (ConcreteHandlerA,

ConcreteHandlerB) age como um tratador de pedidos

e conhece seu sucessor.

• Se um dado objeto é capaz de tratar o pedido ele o faz,

caso contrário o pedido é passado ao próximo tratador no

encadeamento de objetos.




• Exemplo:

• Uma aplicação de e-commerce precisa se comunicar com

vários bancos diferentes para prover aos seus usuários

mais possibilidades de pagamentos, atingindo assim um

número maior de usuários e facilitando suas vidas.

• Ao modelar uma forma de execução do pagamento, dado

que precisamos selecionar um entre vários tipos de

bancos, a primeira ideia que surge é utilizar uma estrutura

de decisão para verificar, dado um parâmetro, qual o

banco correto deve ser utilizado.




• Exemplo:



Chain of Responsibility – Código

• IDBancos.java:

public enum IDBancos {

bancoA, bancoB, bancoC, bancoD

}




• BancoChain.java:

public abstract class BancoChain {

protected BancoChain next;

protected IDBancos identificadorDoBanco;

public BancoChain(IDBancos id) {

next = null;

identificadorDoBanco = id;

}

public void setNext(BancoChain forma) {

if (next == null) {

next = forma;

} else {

next.setNext(forma);

}

}

}




• BancoChain.java:

public void efetuarPagamento(IDBancos id) throws Exception {

if (podeEfetuarPagamento(id)) {

efetuaPagamento();

} else {

if (next == null) {

throw new Exception("banco não cadastrado");

}

next.efetuarPagamento(id);

}

}

private boolean podeEfetuarPagamento(IDBancos id) {

if (identificadorDoBanco == id) {

return true;

}

return false;

}

protected abstract void efetuaPagamento();




• BancoA.java:

public class BancoA extends BancoChain {

public BancoA() {

super(IDBancos.bancoA);

}

@Override

protected void efetuaPagamento() {

System.out.println("Pagamento efetuado no banco A");

}

}




• Client.java:

public class Client {


BancoChain bancos = new BancoA();

bancos.setNext(new BancoB());

bancos.setNext(new BancoC());

bancos.setNext(new BancoD());

try {

bancos.efetuarPagamento(IDBancos.bancoC);

bancos.efetuarPagamento(IDBancos.bancoD);

bancos.efetuarPagamento(IDBancos.bancoA);

bancos.efetuarPagamento(IDBancos.bancoB);

} catch (Exception e) {

e.printStackTrace();

}

}}



Command



Command

• Apresentação:

• Este padrão de projeto representa comandos como

objetos.

• Isto possibilita realizar requisições a objetos sem o

conhecimento de como a operação é executada ou o

destinatário (receiver) da requisição.



Command

• Aplicabilidade:

• Objetos podem ser parametrizados pela ação a executar,

como, por exemplo, uma opção de menu ou um botão em

uma barra de ferramentas.

• Opcionalmente, um comando pode especificar uma

operação de desfazer (undo), permitindo reverter os efeitos no próprio comando. Assim, a interface Command

deve declarar uma operação (método) – undo() – para

realizar tal operação.



Command

• Aplicabilidade:

• Neste caso, as ações realizadas por execute() são

armazenadas em uma lista de histórico e o nível de

execuções e reversões pode ser ilimitado simplesmente

percorrendo a lista de histórico do fim para o início ou do

início para fim.



Command

• Estrutura:



Command – Código

• Loja.java:

public class Loja {

protected String nomeDaLoja;

public Loja(String nome) {

nomeDaLoja = nome;

}

public void executarCompra(double valor) {

Compra compra = new Compra(nomeDaLoja);

compra.setValor(valor);

}

}



Command – Código

• Exemplo:

• Sistema de Pagamento de Loja



Command – Código

• Loja.java:

public class Compra {

private static int CONTADOR_ID;

protected int idNotaFiscal;

protected String nomeDaLoja;

protected double valorTotal;

public Compra(String nomeDaLoja) {

this.nomeDaLoja = nomeDaLoja;

idNotaFiscal = ++CONTADOR_ID;

}

public void setValor(double valor) {

this.valorTotal = valor;

}

public String getInfoNota() {

return new String("Nota fiscal nº: " + idNotaFiscal + "\nLoja: "

+ nomeDaLoja + "\nValor: " + valorTotal);

}

}



Command – Código – ANTI-PATTERN!!!

• Loja.java:

public void executarCompra(double valor, FormaDePagamento frmPag){



if(frmPag == FormaDePagamento.CartaoDeCredito){

new PagamentoCartaoCredito().processarCompra(compra);

} else if(frmPag == FormaDePagamento.CartaoDeDebito){

new PagamentoCartaoDebito().processarCompra(compra);

} else if(frmPag == FormaDePagamento.Boleto){

new PagamentoBoleto().processarCompra(compra);

}

}



Command – Código

• Agora, aplicando o padrão!



Command

• Exemplo:



Command – Código

• PagamentoCommand.java:

public interface PagamentoCommand {

void processarCompra(Compra compra);

}



Command – Código

• PagamentoBoleto.java:

public class PagamentoBoleto implements PagamentoCommand {

@Override

public void processarCompra(Compra compra) {

System.out.println("Boleto criado!\n" + compra.getInfoNota());

}

}



Command – Código – Usando o Padrão!

• Loja.java:

public void executarCompra(double valor, PagamentoCommand frmPag) {



frmPag.processarCompra(compra);

}



Command

• Observação:

• O padrão tem um conceito muito simples, utiliza-

se apenas da herança para agrupar classes e

obrigar que todas tenham uma mesma interface

em comum.

• A primeira vista o padrão pode ser confundido

com o padrão Template Method, pois ambos

utilizam a herança para unificar a interface de

várias classes.



Command

• Observação:

• A diferença básica é que no padrão Command

não existe a ideia de um “algoritmo” que será

executado.

• No padrão Template Method as subclasses

definem apenas algumas operações, sem alterar o

esqueleto de execução.

• O padrão Command não oferece uma maneira de

execução de suas subclasses, apenas garante que

todas executem determinada requisição.



Interpreter



Interpreter

• Apresentação:

• Padrão de projeto utilizado para modelar a gramática para

uma linguagem específica a um domínio de problemas.



Interpreter

• Aplicabilidade:

• Analisadores de expressões regulares, expressões

algébricas e partituras musicais (um dado som e sua

duração), além de linguagens de consulta (query

language) e protocolos de comunicação são exemplos da

aplicabilidade deste padrão de projeto.



Interpreter

• Estrutura:



Interpreter

• Descrição:

• AbstractExpression declara a operação comum a

todos os elementos na árvore de sintaxe abstrata, enquanto TerminalExpression implementa tal

operação para um determinado elemento terminal (que

não pode ser definido em termos de outros elementos).

• NonterminalExpression implementa a mesma

operação de forma que esta possa ser chamada

recursivamente para cada símbolo na gramática e Context possui a informação que é global ao

interpretador.



Interpreter

• Descrição:

• Como exemplo, tem-se, a seguir, a gramática que define expressões

regulares:



Interpreter

• Exemplo:

• Sistema de Conversão de Algarismos Romanos



Interpreter

• Exemplo:



Interpreter – Código

• Contexto.java:

public class Contexto {

protected String input;

protected int output;

public Contexto(String input) {

this.input = input;

}

public String getInput() {

return input;

}

public void setInput(String input) {

this.input = input;

}

public int getOutput() {

return output;

}

public void setOutput(int output) {

this.output = output;

}

}




• NumeroRomanoInterpreter.java:

public abstract class NumeroRomanoInterpreter {

public void interpretar(Contexto contexto) {

if (contexto.getInput().length() == 0) {

return;

}

// Os valores nove e quatro são os únicos que possuem duas casas

// Ex: IV, IX

if (contexto.getInput().startsWith(nove())) {

adicionarValorOutput(contexto, 9);

consumirDuasCasasDoInput(contexto);

} else if (contexto.getInput().startsWith(quatro())) {


consumirDuasCasasDoInput(contexto);

} else if (contexto.getInput().startsWith(cinco())) {


consumirUmaCasaInput(contexto);

}

// Os valores de um são os únicos que repetem, ex: III, CCC, MMM

while (contexto.getInput().startsWith(um())) {


consumirUmaCasaInput(contexto);

}

}

private void consumirUmaCasaInput(Contexto contexto) {

contexto.setInput(contexto.getInput().substring(1));

}

private void consumirDuasCasasDoInput(Contexto contexto) {

contexto.setInput(contexto.getInput().substring(2));

}

}




• NumeroRomanoInterpreter.java:

public abstract class NumeroRomanoInterpreter {

...

public abstract String um();

public abstract String quatro();

public abstract String cinco();

public abstract String nove();

public abstract int multiplicador();

}




• UmDigitoRomano.java:

public class UmDigitoRomano extends NumeroRomanoInterpreter {

@Override

public String um() {

return "I";

}

@Override

public String quatro() {

return "IV";

}

@Override

public String cinco() {

return "V";

}

@Override

public String nove() {

return "IX";

}

@Override

public int multiplicador() {

return 1;

}

}




• DoisDigitoRomano.java:

public class DoisDigitosRomano extends NumeroRomanoInterpreter {

@Override

public String um() {

return "X";

}

@Override

public String quatro() {

return "XL";

}

@Override

public String cinco() {

return "L";

}

@Override

public String nove() {

return "XC";

}

@Override

public int multiplicador() {

return 10;

}

}




• Cliente.java:


ArrayList interpretadores = new ArrayList();

interpretadores.add(new QuatroDigitosRomano());

interpretadores.add(new TresDigitosRomano());

interpretadores.add(new DoisDigitosRomano());

interpretadores.add(new UmDigitoRomano());

String numRomano = "CXCIV";

Contexto contexto = new Contexto(numeroRomano);

for (NumeroRomanoInterpreter numRomInterpreter : interpretadores) {

numRomInterpreter.interpretar(contexto);

}

System.out.println(numRomano+"="+Integer.toString(contexto.getOutput()));

}



Iterator



Iterator

• Apresentação:

• Este padrão de projeto fornece uma interface comum

para que uma coleção de objetos possa ser percorrida

sem, no entanto, que a aplicação tome conhecimento de

como tais objetos estão agrupados.



Iterator

• Aplicabilidade:

• A utilização deste padrão de projeto possibilita à

aplicação ter acesso ao conteúdo de um objeto agregado

sem que sua representação interna seja exposta.

• A coleção de objetos pode ser percorrida em ambas as

direções, de acordo com a declaração da interface.



Iterator

• Estrutura:



Iterator

• Descrição:

• Collection é a interface comum que disponibiliza a

assinatura do método createIterator(), entre outros,

que deve ser implementado pelas classes descendentes

e cujas implementações permitem o percorrimento da

coleção de objetos (agregado).

• Assim, cada coleção concreta implementa o algoritmo de

percorrimento de acordo com a representação de seus

dados, retornando à aplicação uma referência à interface Iterator, que apresenta uma interface comum utilizada

para percorrer da coleção de objetos.



Iterator

• Exemplo:

• Exibir lista de canais de tv por assinatura



Iterator – Código

• Representação Simples:

ArrayList<Canal> arrayListDeCanais = new ArrayList<Canal>();

Canal[] matrizDeCanais = new Canal[5];

for (Canal canal : arrayListDeCanais) {

System.out.println(canal.nome);

}

for (int i = 0; i < matrizDeCanais.length; i++) {

System.out.println(matrizDeCanais[i].nome);

}




• Usando o Padrão:




• AgregadoDeCanais.java:

public interface AgregadoDeCanais {

IteradorInterface criarIterator();

}




• CanaisEsportes.java:

public class CanaisEsportes implements AgregadoDeCanais {

protected ArrayList<Canal> canais;

public CanaisEsportes() {

canais = new ArrayList<Canal>();

canais.add(new Canal("Esporte ao vivo"));

canais.add(new Canal("Basquete 2011"));

canais.add(new Canal("Campeonato Italiano"));

canais.add(new Canal("Campeonato Espanhol"));

canais.add(new Canal("Campeonato Brasileiro"));

}

@Override

public IteradorListaDeCanais criarIterator() {

return new IteradorListaDeCanais(canais);

}

}




• Classe que utilizar Matriz:

@Override

public IteradorInterface criarIterator() {

return new IteradorMatrizDeCanais(canais);

}




• IteradorInterface.java:

public interface IteradorInterface {

void first();

void next();

boolean isDone();

Canal currentItem();

}




• IteradorListaDeCanais.java:

public class IteradorListaDeCanais implements IteradorInterface {

protected ArrayList<Canal> lista;

protected int contador;

protected IteradorListaDeCanais(ArrayList<Canal> lista) {

this.lista = lista;

contador = 0;

}

public void first() {

contador = 0;

}

public void next() {

contador++;

}

public boolean isDone() {

return contador == lista.size();

}

public Canal currentItem() {

if (isDone()) {

contador = lista.size() - 1;

} else if (contador < 0) {

contador = 0;

}

return lista.get(contador);

}

}




• IteradorListaDeCanais.java:

public class IteradorMatrizDeCanais implements IteradorInterface {

protected Canal[] lista;

protected int contador;

public IteradorMatrizDeCanais(Canal[] lista) {

this.lista = lista;

}

@Override

public void first() {

contador = 0;

}

@Override

public void next() {

contador++;

}

@Override

public boolean isDone() {

return contador == lista.length;

}

@Override

public Canal currentItem() {

if (isDone()) {

contador = lista.length - 1;

} else if (contador < 0) {

contador = 0;

}

return lista[contador];

}

}




• Cliente.java:


AgregadoDeCanais canaisDeEsportes = new CanaisEsportes();

System.out.println("Canais de Esporte:");

for (IteradorInterface it = canaisDeEsportes.criarIterator(); !it.isDone();

it.next()){

System.out.println(it.currentItem().nome);

}

AgregadoDeCanais canaisDeFilmes = new CanaisFilmes();

System.out.println("\nCanais de Filmes:");

for (IteradorInterface it = canaisDeFilmes.criarIterator(); !it.isDone();

it.next()) {

System.out.println(it.currentItem().nome);

}

}



Mediator



Mediator

• Apresentação:

• Este padrão de projeto provê uma interface unificada a

um conjunto de interfaces em um subsistema, fazendo

com que a comunicação entre os vários objetos do

subsistema seja realizada por um objeto. Desta forma, os

objetos do subsistema deixam de manter relações entre

si, reduzindo, assim, o acoplamento.



Mediator

• Aplicabilidade:

• A aplicabilidade para este padrão de projeto dá-se

quando se quer separar a comunicação que vários

objetos têm entre si através de uma interface bem

definida, diminuindo, assim, suas interdependências.



Mediator

• Estrutura:



Mediator

• Descrição:

• Objetos Colleague são desacoplados uns dos outros.

• As classes concretas de Colleague “conversam” com a

implementação concreta de Mediator, que, por sua vez,

conduz a troca de mensagens entre objetos Colleague.



Mediator

• Exemplo:

• Sistema de troca de mensagens entre celulares de

diferentes SOs



Memento



Memento

• Apresentação:

• Este padrão de projeto baseia-se em dois objetos: o objeto Originator e o objeto Caretaker.

• O primeiro é qualquer objeto da aplicação, enquanto o

segundo necessita realizar algum processamento no primeiro,

mas precisa que o estado inicial possa ser restaurado.

• Desta forma, o conceito de encapsulamento não é violado, o

que, de outra forma, exporia à aplicação os detalhes de

implementação do objeto que sofrerá o processamento.



Memento

• Aplicabilidade:

• Quando se deseja realizar algum processamento

temporário em determinado objeto da aplicação, o padrão

de projeto Memento é aplicado de tal forma que um

“instantâneo” (snapshot) do estado (ou de parte deste) do

objeto em questão seja salvo para ser restaurado

posteriormente ao processamento realizado.



Memento

• Estrutura:



Memento

• Descrição:

• O objeto Caretaker deve realizar algum processamento

com o objeto Originator, possivelmente mudando seu

estado.

• Antes que isto aconteça, o objeto Caretaker pede ao

objeto Originator por uma referência a Memento,

realiza o processamento desejado e devolve a referência Memento ao objeto Originator para que seu estado

seja restaurado.



Memento

• Exemplo:

• Editor de texto, com recurso de recuperação de estados

anteriores ao atual.



Observer



Observer

• Apresentação:

• O objetivo deste padrão de projeto é definir uma relação

de dependência de um para muitos entre um conjunto de

objetos.

• Desta forma, quando um objeto muda de estado todos

seus dependentes são notificados de tal mudança.



Observer

• Apresentação:

• De outra forma, se pode dizer que um ou mais objetos,

denominados observadores (observers) ou ouvintes

(listeners) são registrados (ou se registram) para

observervar um determinado evento que pode acontecer

por meio de um objeto observado (subject).

• Normalmente, este objeto observado mantém uma

coleção de observadores.



Observer

• Aplicabilidade:

• Este padrão de projeto é utilizado quando se deseja

observar um evento externo, tal como, uma ação do

usuário, o que é muito empregado em programação

orientada a eventos.

• Mudanças no valor de propriedades (variáveis) também

empregam o uso deste padrão de projeto.



Observer

• Aplicabilidade:

• A arquitetura Modelo-Visão-Controlador (MVC – Model-

View-Controller) faz uso freqüente deste padrão, pois ele

é empregado de forma a criar um baixo acoplamento

entre o Modelo e a Visão fazendo com que uma mudança

no Modelo alerte os seus observadores, que são, neste

caso, as visões.



Observer

• Estrutura:



Observer

• Descrição:

• A classe Subject é utilizada por classes concretas como

interface comum para que objetos possam se registrar como

observadores, bem como para que possam ser removidos,

sendo que cada classe concreta pode ter uma coleção de

observadores.

• Qualquer classe pode ser um observador desde que implemente a interface Observer e se registre com uma

classe concreta de Subject. Assim, os observadores serão

notificados sempre que o estado da classe concreta de Subject que os tenha registrado mude.



Observer

• Exemplo:

• Representação de dados, em diversos formatos (Tabela,

Porcentagem, Gráfico Barras, Etc.)



State



State

• Apresentação:

• Este padrão de projeto permite que um objeto modifique

seu comportamento de acordo com a mudança de seu

estado interno.

• Assim, tem-se a impressão que o objeto muda sua classe.



State

• Aplicabilidade:

• O uso deste padrão de projeto dá-se quando o

comportamento de um objeto depende de seu estado e

este comportamento deve se modificar em tempo de

execução (runtime) de acordo com este estado e,

também, quando muitas declarações condicionais (if-

else-if-else) dependem do estado do objeto.



State

• Aplicabilidade (Cont). :

• Neste caso, cada operação, que é realizada de acordo

com um valor constante, deve ser transferida para uma

classe própria.

• Esta transferência permite tratar o estado do objeto como

um objeto por si só.



State

• Estrutura:



State

• Descrição:

• Context pode ser qualquer classe na aplicação que

contém vários estados internos.

• Quando o método request() é invocado sobre o objeto

contexto, o processamento é delegado ao objeto estado (State).



State

• Descrição (Cont.):

• Assim, os estados concretos (ConcreteStateA,

ConcreteStateB) tratam (manipulam) as requisições

provenientes do contexto e os estados concretos têm

suas próprias implementações para o tratamento da

requisição.

• Desta forma, quando Context muda seu estado (o(s)

valor(es) de seu(s) atributo(s) é(são) alterado(s)), seu

comportamento também muda.



State

• Exemplo:

• Gerenciar os vários estados de um personagens de

game. (Ex: Mario)



Strategy



Strategy

• Apresentação :

• Este padrão de projeto define uma família de algoritmos,

os encapsula e os torna intercambiáveis.

• Estes algoritmos podem variar independente da aplicação

cliente que os usa.



Strategy

• Aplicabilidade:

• Este padrão de projeto provê uma forma de configurar

uma classe com um de vários comportamentos ou

algoritmos.

• Além disto, é possível esconder da aplicação as

estruturas de dados, possivelmente complexas, utilizadas

pelos diversos algoritmos.



Strategy

• Aplicabilidade (Cont.):

• Isto permite que diferentes regras de negócios possam

ser utilizadas dependendo do contexto no qual elas

ocorram, significando que este padrão de projeto fornece

um meio de configurar uma classe com um entre vários

comportamentos.



Strategy

• Estrutura:



Strategy

• Descrição:

• Encapsula algoritmos em classes, permitindo que eles

possam variar independente da aplicação cliente que os

usa. Isto possibilita a aplicação do princípio denominado

Princípio Aberto-Fechado (Open-Closed Principle), no

qual uma classe está aberta para extensões enquanto

mantém-se fechado para alterações.



Strategy


• Tal princípio é alcançado pelo uso deste padrão de

projeto, pois a aplicação cliente faz uso de uma classe

base (classe abstrata ou interface) e os detalhes de

implementação estão presentes em classes derivadas.

• A aplicação cliente não sofre impacto no caso do

aumento de classes derivadas, nem tampouco com

eventuais mudanças que essas classes venham a sofrer.



Strategy


• Com isto, a aplicação cliente minimiza o acoplamento,

pois mantém um vínculo com a abstração (classe abstrata

ou interface) e não com uma implementação específica.



Strategy

• Exemplo:

• Cálculo de impostos de acordo com o cargo do

funcionário.



Template Method



Template Method

• Apresentação:

• Padrão de projeto cuja função é generalizar um processo,

em um nível mais genérico, em um conjunto de passos,

permitindo que etapas comuns sejam implementadas e

que etapas específicas tenham suas implementações

realizadas por classes descendentes.

• Em outras palavras, este padrão permite que subclasses

de uma classe comum possam variar partes de um

algoritmo mais geral.



Template Method

• Aplicabilidade:

• Partes de um algoritmo genérico são implementadas em

uma classe comum a partir da qual suas subclasses

podem ou devem implementar as partes específicas.



Template Method

• Estrutura:



Template Method

• Descrição:

• A classe AbstractClass possui o método

templateMethod() e as assinaturas de métodos

abstratos, usados pelo método template, que devem ser

implementados por classes descendentes.

• Uma vez que a classe contendo o método com os passos

comuns (ou genéricos) tenha sido criada, várias classes

concretas podem existir, cada uma implementando as

partes específicas do algoritmo.



Template Method


• Algumas vezes um algoritmo genérico pode-se valer de

passos que, se não implementados por classes

descendentes, podem não existir ou são padronizados.

• Neste caso, as classes descendentes podem escolher ou

não realizar suas implementações.



Template Method


• Outras vezes, dependendo do projeto, AbstractClass

pode ser, na verdade, uma classe concreta, cujos passos

específicos de um algoritmo podem ou devem ser

implementadas por classes descendentes.



Template Method

• Exemplo:

• Ordenação de uma Playlist de MP3



Visitor



Visitor

• Apresentação:

• Representa uma operação que é executada em uma

estrutura de objetos.

• Novas operações são definidas sem, no entanto,

conhecer as classes dos objetos sobre as quais elas

serão executadas.



Visitor

• Aplicabilidade:

• Este padrão de projeto pode ser utilizado quando uma

estrutura de objetos contém muitas classes com

interfaces diferentes e se deseja executar operações

distintas ou sem relação entre si.



Visitor

• Aplicabilidade (Cont.):

• Isto evita a “poluição” de código e mantém códigos

relacionados em uma única classe.

• Além disto, normalmente a frequência de mudanças nas

estruturas de objetos é pequena, enquanto que novas

operações podem ser acrescentadas à medida que os

requisitos se modificam.



Visitor

• Estrutura:



Visitor

• Descrição:

• Este padrão de projeto é aplicado quando há necessidade

de se executar operações semelhantes em objetos de

diferentes tipos agrupados em uma estrutura,

possivelmente uma coleção.

• Ele também fornece um meio prático para o acréscimo de

novos visitors que estendem funcionalidades pré-

existentes sem que o código seja modificado.



Visitor

• Exemplo:

• Representação de Árvore Binária

padrões de projeto de software -...

Documents