Padrões de Projeto de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com
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).
Catálogo de Padrões (GoF) E. Gamma and R. Helm and R. Johnson and J. Vlissides. Design Patterns 5 - Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.
Catálogo de Padrões (GoF) 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.
Catálogo de Padrões (GoF) 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.
Catálogo de Padrões (GoF) 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
Catálogo de Padrões (GoF) Como os padrões resolvem os problemas? 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
Catálogo de Padrões (GoF) 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
Catálogo de Padrões (GoF) 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
Formato dos Padrões (GoF) 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
Formato dos Padrões (GoF) 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
Formato dos Padrões (GoF) 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
Formato dos Padrões (GoF) Exemplo: 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
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
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.
Padrões de Criação 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 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.
Padrões de Criação 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.
Abstract Factory Implementação 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()).
Abstract Factory Implementação 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();
Abstract Factory Código MotifWidgetFactory.java class MotifWidgetFactory extends WidgetFactory { public Botao criarbotao() { return new BotaoMotif();
Abstract Factory Código QtWidgetFactory.java class QtWidgetFactory extends WidgetFactory { public Botao criarbotao() { return new BotaoQt();
Abstract Factory Código Botao.java abstract class Botao { public abstract void desenhar();
Abstract Factory Código BotaoMotif.java class BotaoMotif extends Botao { public void desenhar(){ System.out.println("Eu sou um botao Motif!");
Abstract Factory Código BotaoQt.java class BotaoQt extends Botao { public void desenhar(){ System.out.println("Eu sou um botao Qt!");
Abstract Factory Código 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
Factory Method
Factory Method
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 Estrutura
Factory Method Estrutura
Factory Method Estrutura
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;
Factory Method Consequências Vantagens: Conecta hierarquias de classes paralelas Ocorrem quando uma classe delega alguma das suas responsabilidades para uma classe separada;
Factory Method Consequências Desvantagens: Os clientes podem ter que fornecer subclasses da classe Creator somente para criar um objeto ConcreteProduct em particular;
Factory Method Consequências 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);
Factory Method Consequências 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();
Factory Method Código 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();
Factory Method Código 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!");
Factory Method Código MeuDocumento.java class MeuDocumento extends Documento { private String word = "Word"; private String excel = "Excel"; String getword() { return this.word; String getexcel() { return this.excel;
Factory Method Código FactoyMethodTest.java public class FactoyMethodTest { public static void main(string[] args) { 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
Factory Method Código 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 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 Implementação (Dicas)
Singleton Implementação (Dicas) 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;
Singleton Implementação (Dicas) 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 contraprodutivo 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 ComputadorDirector ~ builder: ComputadorBuilder + ComputadorDirector(ComputadorBuilder) + buildcomputador() : Computador ComputadorBuilder # computador: Computador ~builder + createcomputador() : void + addplacamae() : void + addharddisks() : void + getcomputador() : Computador ComputadorBasicoBuilder + createcomputador() : void + addplacamae() : void + addharddisks() : void ComputadorGamesBuilder + createcomputador() : void + addplacamae() : void + addharddisks() : void Serv idorbuilder + createcomputador() : void + addplacamae() : void + addharddisks() : void
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 { void convertercaractere(char c) { 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 { void convertercaractere(char c) { 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 { public static void main(string[] args) { 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
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.
Padrões Estruturais 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.
Padrões Estruturais Adapter Bridge Composite Decorator Façade Flyweight Proxy
Padrões Comportamentais
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 Comportamentais 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-paramuitos.
Padrões Comportamentais Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor
Chain of Responsibility
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.
Chain of Responsibility 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.
Chain of Responsibility Estrutura:
Chain of Responsibility 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.
Chain of Responsibility 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.
Chain of Responsibility Exemplo:
Chain of Responsibility Código IDBancos.java: public enum IDBancos { bancoa, bancob, bancoc, bancod
Chain of Responsibility Código 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);
Chain of Responsibility Código 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();
Chain of Responsibility Código BancoA.java: public class BancoA extends BancoChain { public BancoA() { super(idbancos.bancoa); @Override protected void efetuapagamento() { System.out.println("Pagamento efetuado no banco A");
Chain of Responsibility Código Client.java: public class Client { public static void main(string[] args) { 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){ Compra compra = new Compra(nomeDaLoja); compra.setvalor(valor); 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) { Compra compra = new Compra(nomeDaLoja); compra.setvalor(valor); frmpag.processarcompra(compra);
Command Observação: O padrão tem um conceito muito simples, utilizase 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;
Interpreter Código 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())) { adicionarvaloroutput(contexto, 4); consumirduascasasdoinput(contexto); else if (contexto.getinput().startswith(cinco())) { adicionarvaloroutput(contexto, 5); consumirumacasainput(contexto); // Os valores de um são os únicos que repetem, ex: III, CCC, MMM while (contexto.getinput().startswith(um())) { adicionarvaloroutput(contexto, 1); consumirumacasainput(contexto); private void consumirumacasainput(contexto contexto) { contexto.setinput(contexto.getinput().substring(1)); private void consumirduascasasdoinput(contexto contexto) { contexto.setinput(contexto.getinput().substring(2));
Interpreter Código 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();
Interpreter Código 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;
Interpreter Código 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;
Interpreter Código Cliente.java: public static void main(string[] args) { 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);
Iterator Código Usando o Padrão:
Iterator Código AgregadoDeCanais.java: public interface AgregadoDeCanais { IteradorInterface criariterator();
Iterator Código 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);
Iterator Código Classe que utilizar Matriz: @Override public IteradorInterface criariterator() { return new IteradorMatrizDeCanais(canais);
Iterator Código IteradorInterface.java: public interface IteradorInterface { void first(); void next(); boolean isdone(); Canal currentitem();
Iterator Código 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);
Iterator Código 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];
Iterator Código Cliente.java: public static void main(string[] args) { 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 (ifelse-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 Descrição (Cont.): 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 Descrição (Cont.): 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 Descrição (Cont.): 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 Descrição (Cont.): 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