Ministrio da Educao Universidade Tecnolgica Federal do Paran
Campus Medianeira
Padres de Projeto v3: Catlogo GoF
Romualdo Rubens de Freitas [email protected]
Padres de Projeto
Romualdo Rubens de Freitas ii
Licena
O uso deste material est condicionado licena Creative Commons Attribution-NonCommercial-Share Alike 3.0 Brazil, que pode ser obtida mediante o acesso ao endereo http://creativecommons.org/licenses/by-nc-sa/3.0/br/.
Resumidamente, com este material possvel realizar:
Cpia, distribuio, exibio e execuo;
Criao de obras derivadas.
Tendo em mente as seguintes condies:
Deve-se dar crdito ao autor original;
proibido o uso deste material com fins financeiros;
Se este material for alterado, transformado ou outra obra for criada a partir dele, a obra resultante somente poder ser distribuda mediante licena idntica a esta.
Padres de Projeto
Romualdo Rubens de Freitas iii
Apresentao
Muito se discute quanto utilizao dos padres de projeto. Alguns
argumentam que a proliferao de classes acaba por inchar o cdigo da
aplicao. Outros, no entanto, atestam que os padres de projeto fazem parte
das assim chamadas boas prticas e que seu uso proporciona maior clareza
no cdigo, traz facilidades de manuteno, promove a separao de
atribuies e garante extensibilidade medida que novas funcionalidades so
agregadas ao sistema.
Independente de opinies fica claro que a utilizao de boas prticas em
projetos de software garante inmeras vantagens, tais como melhor
entendimento do problema que se deseja resolver com a aplicao; diviso de
responsabilidades, sendo que cada parte ou camada executa um conjunto de
funcionalidades inter-relacionadas; facilidade na incluso de novos processos
e, no menos importante, manutenibilidade. Estas vantagens so apresentadas
tendo em vista a codificao. Normalmente, o desenvolvimento de uma
aplicao de software deve levar em considerao, alm do desenvolvimento,
igualmente as etapas de Anlise e Projeto, nas quais o uso de boas prticas
leva a um projeto de software, como um todo, que ser bem entendido por
todos da equipe de desenvolvimento, bem como por aqueles que venham a
integr-la posteriormente, alm, claro, daqueles dos prprios usurios.
Os padres de projeto permitem a reusabilidade de projetos e
arquiteturas e evitam seu comprometimento, alm de auxiliar na documentao
e na manuteno de sistemas existentes. De um modo geral, um padro tem 4
(quatro) elementos principais: nome, uma ou duas palavras usadas para descrever o problema no qual o padro aplicvel, suas solues e
conseqncias; problema, que explica o problema e seu contexto e quando aplicar o padro; soluo, descreve os elementos que constituem o projeto, seus relacionamentos, responsabilidades e colaboraes; e conseqncias, descrevem os resultados e benefcios da aplicabilidade do padro. Desta
Padres de Projeto
Romualdo Rubens de Freitas iv
forma, um padro de projeto nomeia, abstrai e identifica aspectos chave de
uma estrutura de projeto comum que o torna til na criao de um projeto
orientado a objetos reusvel.
Padres de projeto possibilitam aplicar solues a problemas freqentes,
tambm denominados de recorrentes. Mas, na maioria dos casos, muitos
consideram o entendimento destas solues um passo a mais na
complexidade do desenvolvimento de aplicaes de software e terminam
negligenciando seu uso. Na verdade, esta negligncia acaba por gerar um
contraponto no uso de padres de projeto, pois, na maioria dos casos, uma
soluo semelhante apresentada pelos padres de projeto utilizada. Este
contraponto se d pelo fato de o problema ser resolvido com uma codificao
muito semelhante quela que seria feita se os padres de projeto fossem
aplicados. Esta prtica conhecida como anti-pattern (anti-padro), que ,
basicamente, o uso de prticas no recomendas. Isto se d pelas seguintes
caractersticas (a) uma dada soluo de cdigo que utilizada com freqncia
e que, a princpio, representa ser uma boa soluo, mas que, ao longo do
tempo, torna-se um complicador na evoluo da aplicao de software ou em
sua manuteno; e (b) tal soluo no adequada pode ser substituda por um
padro de projeto.
Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides organizam
os 23 padres de projeto apresentados no livro Design Patterns: Elements of Reusable Object-Oriented Software de acordo com seus propsitos e escopo. Esta classificao apresentada na Tabela 1.
Padres de Projeto
Romualdo Rubens de Freitas v
Propsito Criao Estrutural Comportamental
Escopo
Classe Factory Method Adapter (classe) Interpreter Template Method
Objeto
Abstract Factory Builder Prototype Singleton
Adapter (objeto) Bridge Composite Decorator Faade Flyweight Proxy
Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor
Tabela 1: Classificao dos Padres de Projeto.
Esta classificao tornou-se conhecida como Catlogo GoF, sendo que
GoF significa Gang of Four ou Grupo dos Quatro, em ingls, como aluso aos
quatro autores do clebre livro sobre padres de projetos publicado em 1995.
Quando se fala em projeto de software uma notao grfica para
expressar as intenes do projetista importante. Entretanto, uma notao
grfica til para demonstrar o produto, que o resultado final do processo de
projeto na forma de relacionamentos entre classes e objetos. Para se obter um
projeto reutilizvel preciso registrar decises, alternativas e benefcios, bem
como criar exemplos concretos, que permitam verificar o projeto em ao.
No livro de Erich Gamma et al, alm da notao grfica e exemplos1, os
padres de projeto so descritos de acordo com uma estrutura textual
considerada consistente. O objetivo desta estrutura tornar os padres de
projeto mais fceis de aprender, comparar e usar e apresentada no Quadro
1.
1 Os exemplos apresentados no livro esto escritos na linguagem Smalltak e C++.
Padres de Projeto
Romualdo Rubens de Freitas vi
Nome e Classificao O nome descreve a essncia do padro e a classificao reflete as divises apresentadas na Tabela 1.
Inteno Uma breve declarao sobre o objetivo do padro, sua lgica e inteno e a que questo de projeto ou problema ele resolve.
Conhecido como Outros nomes, caso existam, pelos quais o padro conhecido.
Motivao Apresenta uma cenrio que ilustra um problema de projeto e como as estruturas de classes e objetos no padro resolvem o problema.
Aplicabilidade Situaes nas quais o padro aplicvel, exemplos de projetos ruins que o padro pode resolver e como reconhecer tais situaes.
Estrutura Apresenta a representao grfica das classes usando uma notao baseada na OMT (Object Modeling Technique), entre outras.
Participantes Classes e/ou objetos que participam no padro e suas responsabilidades.
Colaboraes Como os participantes colaboram para conduzir suas responsabilidades.
Conseqncias Como o padro suporta seus objetivos, quais os benefcios e resultados do uso do padro e que aspecto do sistema o padro permite que possa variar independentemente.
Implementao Que cuidados, dicas e tcnicas devem ser utilizadas quando o padro for implementado e se h questes especficas a uma determinada linguagem.
Exemplo Fragmentos de cdigo de como o padro pode ser implementado.
Usos Conhecidos Exemplos do padro em sistemas reais. Padres Relacionados Que padres de projeto se relacionam, importantes
diferenas e com quais padres pode ser usado. Quadro 1: Estrutura para descrio dos padroes de projeto utilizada no Catlogo GoF.
Alm da descrio textual e outras j citadas apresentada por Erich
Gamma et al, vrias referncias apresentam os padres do Catlogo GoF de
acordo com seus propsitos, descrevendo os padres de criao, estruturais e,
por fim, os comportamentais. Este material, por outro lado, utiliza outra ordem
de apresentao. Tal ordem baseia-se no grau de complexidade de cada
padro, permitindo que o leitor possa ganhar entendimento sobre os padres
de projeto do Catlogo GoF aos poucos. Mesmo assim, ao lado de cada
Padres de Projeto
Romualdo Rubens de Freitas vii
padro informado qual o seu propsito se de criao, estrutural ou
comportamental.
Assim, este material proporciona ao leitor informaes sobre Padres de
Projeto provenientes de vrias fontes, entre livros, artigos e sites na Internet, a
partir dos quais se fez uma compilao de tal forma que o leitor possa, com
certa facilidade, obter conhecimento sobre solues para problemas que
ocorrem com freqncia. As referncias consultadas encontram-se ao final
deste material, sob o ttulo Referncias.
Padres de Projeto
Romualdo Rubens de Freitas viii
SUMRIO Introduo ......................................................................................................... 9 Singleton Criao ........................................................................................ 12 Factory Method Criao .............................................................................. 17 Abstract Factory Criao ............................................................................ 22 Command Comportamento ........................................................................ 26 Chain of Responsibility Comportamento .................................................. 30 Observer Comportamento .......................................................................... 33 Adapter Estrutura ........................................................................................ 37 Faade Estrutura ......................................................................................... 40 Prototype Criao ....................................................................................... 43 Decorator Estrutura .................................................................................... 46 Builder Criao ............................................................................................ 50 Template Method Comportamento ............................................................ 53 Iterator Comportamento ............................................................................. 56 Composite Estrutura ................................................................................... 59 State Comportamento ................................................................................. 63 Strategy Comportamento ........................................................................... 65 Proxy Estrutura ........................................................................................... 68 Visitor Comportamento ............................................................................... 71 Memento Comportamento .......................................................................... 74 Mediator Comportamento ........................................................................... 77 Bridge Estrutura .......................................................................................... 80 Flyweight Estrutura ..................................................................................... 83 Interpreter Comportamento ........................................................................ 86 REFERNCIAS ................................................................................................ 89
Padres de Projeto
Romualdo Rubens de Freitas 9
Introduo
O Projeto Orientado a Objetos enfatiza na definio de objetos de
software e em como eles colaboram entre si. Esta colaborao depende de
como os objetos necessitam saber sobre questes internas uns dos outros.
Alm de vrios conceitos e princpios que so empregados no projeto de
um software orientado a objetos, dois princpios: coeso e acoplamento, voltados qualidade do projeto, devem ser considerados para assegurar a sua
qualidade. Tais princpios envolvem uma constante procura pela melhor forma
de organizar o cdigo para que ele seja fcil de escrever e de compreender,
alm de facilitar mudanas futuras.
Algumas questes devem ser levadas em considerao quando se
projeta um software orientado a objetos:
Manter cdigo propcio a mudanas to prximo quanto possvel;
Permitir que cdigo no relacionado sofra mudanas independentes;
Diminuir a duplicidade de cdigo.
As questes mencionadas tm uma relao muito prxima com
qualidade de cdigo e, neste sentido, a coeso e o acoplamento so os
princpios empregados com o intuito de se chegar a um projeto de qualidade,
sendo que o objetivo destes princpios o de se atingir a maior coeso e o
menor acoplamento possvel.
A coeso mede quo bem as partes de um objeto suportam o mesmo
propsito. Esta medida considera uma boa definio do propsito do objeto e
se cada uma de suas partes contribui diretamente para atingir o propsito
desejado. Para que um objeto atinja uma alta coeso ele deve ter um propsito
bem definido e todas as suas partes devem contribuir para que este propsito
seja alcanado. Na baixa coeso ou o objeto possui um propsito ambguo,
Padres de Projeto
Romualdo Rubens de Freitas 10
executando mltiplas tarefas, por exemplo, ou nem todas as suas partes
contribuem para o propsito desejado ou ambos.
Quando uma classe projetada para realizar uma determinada tarefa,
seus comportamentos, dados e associaes permitem que sua tarefa seja
executada a contento. Se uma classe possui comportamentos no
relacionados ao seu propsito, dados tambm no relacionados possivelmente
sero acrescentados sua definio e seus comportamentos devero decidir
se devem ou no realizar determinada tarefa. Se um comportamento
freqentemente gasta mais tempo em descobrir o que fazer e no em como
fazer, provavelmente, a classe desse objeto tem baixa coeso.
Infelizmente, altos nveis de coeso so difceis de serem obtidos, nem
sempre possvel descrever uma classe com um nico propsito. Neste caso,
importante saber o custo benefcio de quando e por que sacrificar a coeso.
O acoplamento mede o grau de dependncia entre objetos. Se um
objeto capaz de realizar a tarefa para a qual ele foi concebido sem a
interferncia de outros objetos no sistema, ento se diz que h um fraco
acoplamento, ou seja, quanto menor o acoplamento maior a independncia
de um determinado objeto em relao aos outros objetos do sistema; ao passo
que, quando um objeto necessita de um ou mais objetos para realizar suas
tarefas se diz que h um forte acoplamento. Lidar com um objeto
problemtico, pois suas conexes com outros objetos devem ser consideradas.
Em outras palavras, o acoplamento trata dos relacionamentos e
interaes entre objetos com o intuito de se saber se um objeto precisa de
outro para executar sua tarefa. Se um objeto modificado todos os que
dependem dele, provavelmente, sofrero alguma modificao.
A dependncia entre objetos medida sob quatro aspectos dos
relacionamentos entre classes:
Padres de Projeto
Romualdo Rubens de Freitas 11
O nmero de associaes: cada associao que uma classe possui requer manuteno. As associaes devem ser criadas,
mantidas e excludas ao longo do tempo;
O volume de comunicao: enquanto um objeto se comunica ele no realiza seu trabalho. A comunicao importante, mas qual sua
real necessidade? Toda comunicao requer um resposta. medida
que o volume de comunicao aumenta, mais tempo gasto pelo
objeto na interpretao da informao e na deciso de como
responder;
A complexidade da comunicao: mesmo que haja pouca comunicao entre objetos, se ela complexa h um forte
acoplamento, pois ambos os lados necessitam manter regras
adequadas para que a informao seja interpretada corretamente.
Se as regras so modificadas de um lado e no do outro a
comunicao falha;
Um objeto necessita conhecer da estrutura interna ou o estado de outro objeto: a pior forma de acoplamento quando um objeto precisa conhecer o estado de outro objeto antes de realizar a
comunicao, pois este caso viola o conceito de encapsulamento.
Promover uma alta coeso e um baixo acoplamento o objetivo de todo
projeto de software. Algumas vezes, a soluo para problemas de acoplamento
est em uma melhor coeso. Em outras vezes, a coeso e o acoplamento tm
de ser balanceados para se chegar a um projeto de software adequado.
Padres de Projeto
Romualdo Rubens de Freitas 12
Singleton Criao
Apresentao Este padro garante que haja somente uma instncia para uma classe e,
assim, fornece um ponto nico de acesso a ela.
Aplicabilidade Grupos (pools) de objetos para o gerenciamento de threads e conexes
com bases de dados; caixas de dilogo; configuraes de preferncias e de
registros; objetos para logging e objetos que agem como drivers para
dispositivos, tais como impressoras e placas grficas.
Estrutura
Descrio Para que no haja a possibilidade de criao de objetos arbitrrios o
construtor declarado como private. A varivel esttica instance utilizada para armazenar uma instncia da classe Singleton. Como o construtor da classe privado, o nico ponto de entrada para a obteno de
uma referncia para a classe Singleton atravs do mtodo getInstance(), que ser invocado para a obteno desta referncia.
Padres de Projeto
Romualdo Rubens de Freitas 13
Exemplo de Cdigo
Exemplo na API Java
A classe java.lang.Runtime uma classe singleton, cuja instncia obtida mediante uma chamada ao mtodo getRuntime(). Toda aplicao Java possui somente uma instncia desta classe, que permite acesso ao
ambiente no qual a mesma encontra-se em execuo.
Observaes Algumas caractersticas deste padro de projeto merecem ateno
especial. Devido ao fato de usar um construtor privado, o conceito de
polimorfismo torna-se limitado. Outro ponto importante diz respeito a
aplicaes com mltiplas threads. Neste caso, o mtodo getInstance() deve ser escrito de tal forma que vrias threads concorrendo por ele possam
aguardar o momento correto para acess-lo. Assim, sua assinatura passa a
ser:
public synchronized static Singleton getInstance()
Padres de Projeto
Romualdo Rubens de Freitas 14
O sincronismo de mtodos faz com que a aplicao perca desempenho,
tornando-a lenta demais, dependendo do nmero de vezes em que o mtodo
sincronizado invocado.
Uma alternativa criar a instncia da classe assim que ela carregada
pela Mquina Virtual:
Outra opo para minimizar o impacto no uso de threads denominada
double-checked locking. Com esta tcnica2 o sincronismo acontece somente
se a instncia ainda no foi criada:
2 Alguns autores consideram esta tcnica como um padro.
Padres de Projeto
Romualdo Rubens de Freitas 15
Esta tcnica pode apresentar problemas devido otimizao realizada
pelo compilador, que pode retornar a referncia a um objeto a partir de um
construtor antes mesmo que o construtor possa instanciar o objeto. Uma forma
de contornar este possvel problema tomar vantagem do carregador de
classes (class loader) da aplicao:
Padres de Projeto
Romualdo Rubens de Freitas 16
O que acontece neste caso que a classe interna (inner class)
Instance carregada uma nica vez.
Padres Relacionados Abstract Factory, Builder e Prototype.
Anti-Pattern O anti-pattern do padro Singleton diz respeito ao fato de haver duas ou
mais instncias da classe em questo, uma para cada classe que queira
acessar suas informaes, o que acabaria levando a um aumento na criao
de objetos e na sua conseqente remoo pelo coletor de lixo (garbage
collector), quando for o caso.
Padres de Projeto
Romualdo Rubens de Freitas 17
Factory Method Criao
Apresentao Conhecido tambm como Construtor Virtual ou simplesmente Factory,
este padro fornece uma interface para a criao de objetos, permitindo que as
classes descendentes decidam qual objeto instanciar. A criao de objetos com
um mtodo de factory permite maior flexibilidade em relao criao
realizada antecipadamente, pois tal criao condicional ao objeto que
realmente se deseja criar. Em contrapartida, sempre h a necessidade de se
derivar uma nova classe especfica a partir da interface Creator.
Mtodos factory podem ser utilizados de duas formas: (1) Creator uma classe abstrata e no fornece uma implementao para o mtodo factory,
forando as classes derivadas a faz-lo, ou fornece uma implementao
padro, permitindo que as classes derivadas sejam diferentes de sua classe
base, se necessrio; (2) a forma mais comum de implementao deste padro
a utilizao de um mtodo factory parametrizado, que criar o objeto
adequado de acordo com o parmetro que o identifica. Neste caso, todos os
objetos implementam a interface Product.
Quando se programa para uma interface possvel que novas classes
possam ser agregadas ao sistema sem a necessidade de maiores mudanas.
Isto leva a um princpio muito importante no Paradigma Orientado a Objetos:
Uma classe deve estar fechada para modificaes, porm aberta para extenses (Open-Closed Principle). Outro aspecto importante o fato de que a aplicao tem pouco ou nenhum conhecimento de como a classe com a qual
ela est lidando foi implementada, concordando com outro princpio: Programe para uma interface e no para uma implementao, conforme apresentado por Erich Gamma, et al em Design Patterns: elements of reusable object-oriented software.
De uma forma geral, no h nada de errado em se usar o operador new para a criao de instncias concretas de classes. O problema reside no fato
Padres de Projeto
Romualdo Rubens de Freitas 18
de se estar violando o ltimo princpio apresentado no pargrafo anterior.
Quanto maior o nmero de objetos criados a partir de classes concretas, maior
o acoplamento entre estas classes, o que dificulta, em longo prazo, a manuteniblidade e extensibilidade de uma aplicao.
Aplicabilidade A maioria dos frameworks faz uso deste padro possibilitando que uma
poro de cdigo existente seja genrica o suficiente para satisfazer alguns
requisitos e deixando por conta do desenvolver o cdigo especfico,
implementado a partir da base do framework, que v de encontro aos requisitos
para uma dada aplicao.
Estrutura
Descrio
A interface Creator contm, alm de outros, o mtodo factory. Este mtodo deve ser codificado pelas classes concretas que implementam, no caso
de interface, ou herdam, no caso de classe abstrata, da classe Creator.
Todas as classes ConcreteProduct devem implementar a mesma interface de modo que estas sejam referenciadas por sua interface e no por
classes concretas.
Padres de Projeto
Romualdo Rubens de Freitas 19
Exemplo de Cdigo
Padres de Projeto
Romualdo Rubens de Freitas 20
Padres de Projeto
Romualdo Rubens de Freitas 21
Exemplo na API Java
O mtodo getInstance() da classe java.util.Calendar, o mtodo iterator() das classes descendentes da interface java.util.List so exemplos de factories. O primeiro, que tambm um singleton, retorna uma referncia para o calendrio representado pela time
zone (zona horria) e localidade padro. O segundo devolve uma referncia
que permite percorrer a coleo de objetos.
Padres Relacionados Abstract Factory, Template Method e Prototype.
Anti-Pattern Para este padro, o anti-pattern apresenta um forte acoplamento entre o
aplicativo e as vrias classes que descrevem os produtos a serem criados,
pois haver uma referncia para cada ConcretProduct. Isto implica que modificaes futuras podem acrescentar bugs ao cdigo j existente e testado.
Padres de Projeto
Romualdo Rubens de Freitas 22
Abstract Factory Criao
Descrio Este padro prov uma interface, mediante um mtodo factory por
famlia, para a criao de famlias de objetos que possuem algum tipo de
dependncia ou relao sem, no entanto, especificar suas classes concretas.
Aplicabilidade Quando se deseja criar famlias de objetos (produtos) relacionados ou
que possuam algum tipo de dependncia entre si. Um conjunto de
componentes para a interface grfica com usurio um bom exemplo. Cada
sistema operacional possui um sistema grfico diferente, como, por exemplo,
Windows GDI, Motif, GTK+ e Qt, entre outros. O mesmo acontece com drivers
para mouse, placas de vdeo e impressoras. Para cada sistema operacional a
aplicao pode selecionar o conjunto de drivers de acordo com a plataforma na
qual est em execuo.
Aplicaes multi-SGBD (Sistema Gerenciador de Banco de Dados)
tambm so exemplos do uso deste padro de projeto. A aplicao pode
selecionar o conjunto de classes para o modelo de dados de acordo com o
SGBD.
Estrutura
Padres de Projeto
Romualdo Rubens de Freitas 23
Descrio
AbstractFactory define a interface que todas as fbricas concretas (ConcreteFactory1, ConcreteFactory2) devem implementar. As fbricas concretas implementam diferentes famlias de produtos (AbstractProductA, AbstractProductB). Desta forma, a classe que representa um "produto", propriamente dita, jamais tem que ser instanciada.
As interfaces AbstractProductA e AbstractProductB formam as famlias de produtos que podem ser criados.
A classe Client faz uso de AbstractFactory para obter referncias a AbstractProductA e a AbstractProductB. Assim, famlias de produtos podem ser criadas independentes de suas classes concretas.
Exemplo de Cdigo
Padres de Projeto
Romualdo Rubens de Freitas 24
Exemplo na API Java
A classe abstrata java.awt.Toolkit a superclasse para todas as implementaes de Abstract Window Toolkit, permitindo que os componentes
da interface grfica com o usurio sejam vinculados a implementaes nativas
(dependentes da interface grfica especfica, tais como, Motif e GTK+, entre
outras).
Observaes
Padres Relacionados Factory Method, Prototype e Singleton.
Padres de Projeto
Romualdo Rubens de Freitas 25
Anti-Pattern O anti-pattern para o padro de projeto Abstract Factory assemelha-se
ao do padro Factory Method, pois a aplicao manteria um forte acoplamento
com as classes concretas, Leao e Lobo, por exemplo, o que tornaria sua manuteno muito difcil.
Padres de Projeto
Romualdo Rubens de Freitas 26
Command Comportamento
Descrio Este padro de projeto representa comandos como objetos. Isto
possibilita realizar requisies a objetos sem o conhecimento de como a
operao executada ou o destinatrio (receiver) da requisio.
Aplicabilidade Objetos podem ser parametrizados pela ao a executar, como, por
exemplo, uma opo de menu ou um boto em uma barra de ferramentas.
Opcionalmente, um comando pode especificar uma operao de desfazer
(undo), permitindo reverter os efeitos no prprio comando. Assim, a interface
Command deve declarar uma operao (mtodo) undo() para realizar tal operao. Neste caso, as aes realizadas por execute() so armazenadas em uma lista de histrico e o nvel de execues e reverses pode ser ilimitado
simplesmente percorrendo a lista de histrico do fim para o incio ou do incio
para fim.
Estrutura
Padres de Projeto
Romualdo Rubens de Freitas 27
Descrio
A classe Aplicao cria um comando concreto e configura o receiver para que este possa execut-lo. A classe Receiver, que pode ser qualquer classe na aplicao, sabe como executar o trabalho necessrio.
ConcreteCommand responsvel por manter um vnculo entre uma ao (mtodo action()) e um objeto da classe Receiver. Assim, um objeto Invoker invoca o mtodo execute() e ConcreteCommand realiza uma ou mais aes no objeto Receiver. O papel de Command, que pode ser uma interface ou classe abstrata, o de disponibilizar uma interface comum a todas
as classes concretas que a implementam.
Exemplo de Cdigo
Padres de Projeto
Romualdo Rubens de Freitas 28
Exemplo na API Java
A interface java.swing.Action utilizada quando uma mesma funcionalidade deve ser utilizada por mais de um componente (JMenuItem e JButton, por exemplo). A classe java.swing.AbstractAction utilizada como base para a implementao da classe-comando que realizar a operao
necessria e uma referncia a esta passada ao componente em questo
atravs do mtodo setAction().
Observaes
Classes Command desacoplam objetos que invocam operao daqueles que a executam. Alm disto, utilizando o padro de projeto Composite,
possvel criar conjuntos compostos de comandos que so executados em
seqncia.
Padres Relacionados Composite, Memento e Prototype.
Anti-Pattern Separar os comandos a serem executados em classes distintas
mediante uma interface comum tido como uma boa prtica em projetos de
software. Classes que implementam mtodos para realizarem suas tarefas
Padres de Projeto
Romualdo Rubens de Freitas 29
tornam-se inchadas, de difcil manuteno e pouco extensveis. Com isto, tais
classes passam a ter um forte acoplamento com as tarefas (comandos) a
serem realizadas.
Padres de Projeto
Romualdo Rubens de Freitas 30
Chain of Responsibility Comportamento
Apresentao Normalmente, este padro de projeto utilizado em situaes nas quais
se deseja que mais de um objeto possa tratar (manipular) um pedido
(requisio), evitando o acoplamento entre o remetente de um pedido e o seu
destinatrio. Assim, os objetos recebedores so encadeados e o pedido
passado por este encadeamento at que um objeto o trate.
Aplicabilidade Este padro de projeto comumente utilizando quando mais de um
objeto capaz de tratar um pedido e o mesmo no conhecido
antecipadamente. O objeto tratador do pedido deve ser reconhecido
automaticamente.
Um pedido deve ser tratado por um entre vrios objetos sem que o
objeto tratador seja especificado explicitamente.
Estrutura
Descrio
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
contrrio o pedido passado ao prximo tratador no encadeamento de objetos.
Padres de Projeto
Romualdo Rubens de Freitas 31
Exemplo de Cdigo
Padres de Projeto
Romualdo Rubens de Freitas 32
Exemplo na API Java
Observaes O projeto Apache Commons disponibiliza, entre outros, um framework,
denominado Commons Chain (http://commons.apache.org/chain/), que implementa e estende o padro de projeto Chain of Responsibility. Este
framework disponibilizado gratuitamente junto com seu cdigo fonte.
Padres Relacionados Composite.
Anti-Pattern Dado um conjunto de servios, como, por exemplo, validao de dados,
log e filtro de dados e segurana, que devem ser executados por um grupo de
operaes (processamentos), como, por exemplo, um sistema de venda na
qual cada etapa de sua realizao constitui-se em uma operao, cada
processamento estaria acoplado a todos os servios e estes seriam totalmente
dependentes das vrias etapas do processamento do pedido (realizao de um
venda).
Padres de Projeto
Romualdo Rubens de Freitas 33
Observer Comportamento
Apresentao O objetivo deste padro de projeto definir uma relao de dependncia
de um para muitos entre um conjunto de objetos. Desta forma, quando um
objeto muda de estado todos seus dependentes so notificados de tal
mudana. De outra forma, se pode dizer que um ou mais objetos, denominados
observadores (observers) ou ouvintes (listeners) so registrados (ou se registram) para observervar um determinado evento que pode acontecer por meio de um objeto observado (subject). Normalmente, este objeto observado mantm uma coleo de observadores.
Aplicabilidade Este padro de projeto utilizado quando se deseja observar um evento
externo, tal como, uma ao do usurio, o que muito empregado em
programao orientada a eventos. Mudanas no valor de propriedades
(variveis) tambm empregam o uso deste padro de projeto.
A arquitetura Modelo-Viso-Controlador3 (MVC Model-View-Controller)
faz uso freqente deste padro, pois ele empregado de forma a criar um
baixo acoplamento entre o Modelo e a Viso fazendo com que uma mudana
no Modelo alerte os seus observadores, que so, neste caso, as vises.
Estrutura
3 Alguns autores consideram o MVC como um padro de projetos.
Padres de Projeto
Romualdo Rubens de Freitas 34
Descrio
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
coleo 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 sero notificados sempre que o estado da classe concreta de Subject que os tenha registrado mude.
Exemplo de Cdigo
Padres de Projeto
Romualdo Rubens de Freitas 35
Exemplo na API Java
A interface java.util.Observer representa este padro de projeto em Java, juntamente com a classe java.util.Observable, que representa um objeto observvel.
As interfaces ouvintes (listeners) no pacote java.awt.event permitem que uma aplicao Java que faa uso da API Swing para a
construo de interfaces grficas com o usurio (GUI Graphical User
Interface) instalem a si mesmas ou classes auxiliares como ouvintes de
eventos, como, por exemplo, eventos de mouse, teclado e janela. Outra
caracterstica da API Swing que esta segue a arquitetura MVC, na qual o
Padres de Projeto
Romualdo Rubens de Freitas 36
modelo avisa sobre notificaes de mudanas utilizando a infra-estrutura
PropertyChangeNotification. Classes Modelo em Java seguem a especificao JavaBeans, que se comportam como Subject. Classes Viso so associadas com algum item na interface grfica com o usurio e se
comportam como observadores. Assim, enquanto a aplicao est em
execuo, mudanas realizadas no modelo so percebidas pelo usurio porque
as vises (componentes grficos) so atualizadas por meio de notificaes.
Observaes
Padres Relacionados Singleton e Mediator.
Anti-Pattern Quando uma classe se encarrega de observar um determinado evento e
tomar todas as aes necessrias fere o Princpio Aberto-Fechado, pois a classe dever ser modificada para comportar novas aes.
Padres de Projeto
Romualdo Rubens de Freitas 37
Adapter Estrutura
Descrio Padro de projeto que possibilita converter a interface de uma classe em
outra necessria aplicao. Assim, classes com interfaces distintas ou
incompatveis podem trabalhar juntas.
Aplicabilidade Quando h a necessidade de se usar uma classe existente e sua
interface no aquela esperada. Proporciona empregar o princpio de
composio, no qual um objeto adaptado com uma interface modificada.
Alm disto, possvel vincular uma aplicao cliente a uma determinada
interface, permitindo acrescentar novas funcionalidades aps a implementao
deste padro de projeto.
Estrutura
Descrio De acordo com o Diagrama de Classes acima, a aplicao
Aplicao possui uma referncia classe Adapter (classe adaptadora). De posse desta referncia, basta que o mtodo doWork() seja invocado para que este possa realizar a chamada ao mtodo methodA(), na classe
Padres de Projeto
Romualdo Rubens de Freitas 38
Adapter, que, por sua vez, invocar o mtodo methodB() presente na clase Adaptee (classe adaptada).
Exemplo de Cdigo
Exemplo na API Java Este padro muito utilizado na API Swing com as classes
java.awt.event.WindowAdapter e java.awt.event.MouseAdapter, entre outras.
Observaes H dois tipos de adaptadores: objetos adaptadores e classes
adaptadoras. No primeiro caso, a adaptao realizada pelo princpio da composio; enquanto, no segundo caso, a adaptao propiciada pelo
conceito de herana mltipla, conceito este inexistente na linguagem Java.
Padres Relacionados Bridge, Decorator e Proxy.
Anti-Pattern O anti-pattern deste padro de projeto d-se pela existncia de uma ou
mais classes cuja interface difere das interfaces de classes existentes e tm
certa relao com a nova classe ou classes. A codificao do sistema dever
levar em considerao estas possveis novas classes e isto acarretar um
Padres de Projeto
Romualdo Rubens de Freitas 39
inchamento do cdigo medida que tais classes passem a integrar o sistema
existente. O mesmo caso aplica-se quando classes de uma aplicao,
possivelmente legada, tm de ser integradas a novos sistemas.
Padres de Projeto
Romualdo Rubens de Freitas 40
Faade Estrutura
Apresentao Este padro de projeto fornece uma interface nica para um conjunto de
interfaces em um subsistema, definindo uma interface de nvel mais alto que
facilita o uso do subsistema. Desta forma, o acoplamento entre a aplicao
cliente e os subsistemas torna-se minimizado.
Aplicabilidade medida que os sistemas de software evoluem, eles se tornam mais
complexos devido necessidade de se executar um conjunto de operaes de
uma nica vez ou em uma dada seqncia. Quando h necessidade de se criar
um ponto comum de execuo para um conjunto de operaes, o padro de
projeto Faade aplicado para a criao deste ponto comum (ou interface)
para um determinado subsistema, simplificando e unificando um grupo de
classes acessveis mediante o uso de uma nica classe.
Estrutura
Padres de Projeto
Romualdo Rubens de Freitas 41
Descrio
Aplicao1 e Aplicao2 faz uso apenas de Faade, mediante uma chamada ao mtodo metodo(), para acesso aos subsistemas para os quais a fachada foi implementada.
Exemplo de Cdigo
Exemplo na API Java
A classe java.net.URL usada como uma fachada (Faade) para um recurso qualquer na Internet.
Observaes A utilizao deste padro de projeto permite a aplicao do princpio
denominado Princpio do Menor Conhecimento (Principle of Least Knowledge). Este princpio atesta que se deve cuidar com o nmero de
classes com as quais um determinado objeto se relaciona e como este
relacionamento realizado. Evitar o alto acoplamento garante que mudanas
tero pouco ou nenhum impacto na relao entre objetos.
Padres Relacionados Abstract Factory e Mediator.
Padres de Projeto
Romualdo Rubens de Freitas 42
Anti-Pattern A realizao de uma venda implica em uma srie de operaes
necessrias sua efetivao. Estas operaes podem ser, por exemplo, a
baixa no estoque de produtos, a verificao de viabilidade financeira do cliente
para efetuar a compra e a realizao de lanamentos nos registros de contas a
receber e de caixa. Neste caso, o que se deseja a efetivao da venda, mas
este processo est fortemente acoplado a outros subsistemas.
Padres de Projeto
Romualdo Rubens de Freitas 43
Prototype Criao
Apresentao Especifica os tipos de objetos a criar usando uma instncia de prottipo,
criando-os mediante cpia (ou clonagem) deste prottipo. Esta operao
realizada sem que a aplicao saiba qual classe especfica est sendo
instanciada.
Aplicabilidade Em situaes nas quais criar instncias de objetos a partir de hierarquias
de classes complexas e quando a classe de um objeto conhecida somente
em tempo de execuo so exemplos do uso deste padro de projeto.
Estrutura
Descrio A utilizao deste padro de projeto d-se pela existncia de uma classe
base (ou interface) contendo a declarao do mtodo clone() e, dependendo da implementao, mantm um coleo (na forma de um dicionrio, por
exemplo) de classes concretas derivadas da classe base (ou que implementem
a interface).
Padres de Projeto
Romualdo Rubens de Freitas 44
Exemplo de Cdigo
Exemplo na API Java Este padro de projeto a essncia da especificao JavaBean. A
interface java.lang.Cloneable existe para que classes a implementem, e, assim, atestem que podem ser clonadas, mediante a sobre-escrita do mtodo
clone(), disponvel na classe java.lang.Object.
Observaes Eventualmente, padres de projeto de criao competem entre si em
uso. s vezes pode-se utilizar ou o padro de projeto Prototype ou Abstract
Factory. Enquanto em outros casos, ambos so complementos um do outro.
Padres Relacionados Abstract Factory, Composite e Decorator.
Padres de Projeto
Romualdo Rubens de Freitas 45
Anti-Pattern O uso deste padro de projeto destina-se a criar cpias (clones) a partir
de uma instncia denominada prottipo. Assim, o seu anti-pattern a situao
na qual toda vez que uma cpia de um determinado objeto necessria sua
criao deve ser realizada, comprometendo, possivelmente, o desempenho da
aplicao e a quantidade de memria para comportar um nmero elevado de
objetos.
Padres de Projeto
Romualdo Rubens de Freitas 46
Decorator Estrutura
Apresentao Este padro de projeto possibilita o acrscimo de funcionalidades a um
objeto, e no a uma classe, em tempo de execuo, provendo uma alternativa
bem flexvel como mecanismo de extenso de classes. O acrscimo de tais
funcionalidades realizado pelo encadeamento de um conjunto de objetos,
sendo que os primeiros tratam das novas funcionalidades e o ltimo da
funcionalidade original.
Aplicabilidade O uso deste padro de projeto torna possvel estender (decorar) a
funcionalidade de uma classe em tempo de execuo, ao contrrio do
mecanismo de extenso, que acrescenta funcionalidade em tempo de
compilao. Isto acontece quando a classe decoradora cria um invlucro na
classe original recebendo como parmetro em sua construo um objeto da
classe original.
Estrutura
Padres de Projeto
Romualdo Rubens de Freitas 47
Descrio
Objetos Component podem ser usados por si s ou decorados e cada Decorator possui uma referncia a Component, que estendido (classe abstrata) por Decorator. Alm desta referncia, ConcreteDecorators podem ampliar o estado de Component, acrescentando novos mtodos, por exemplo. A ampliao do estado de Component, com o acrscimo de novos mtodos, normalmente realizada antes ou depois dos mtodos de
Component.
Exemplo de Cdigo
Padres de Projeto
Romualdo Rubens de Freitas 48
Exemplo na API Java As classes de entrada e sada de fluxos (I/O stream) contidas no pacote
java.io so um bom exemplo de classes decorativas. Ou seja, possvel, a
Padres de Projeto
Romualdo Rubens de Freitas 49
partir de um objeto criado para um stream decor-lo com um objeto que
converte bytes em caracteres e, por fim, decor-lo com um objeto que recupera
um conjunto de caracteres, como apresentado no quadro a seguir:
BufferedReader br = new BufferedReader(new InputStreamReader(new FileInputStream("receitas.doc")));
Observaes
Padres Relacionados Adapter, Composite e Strategy.
Anti-Pattern Em um cenrio que conta com um conjunto de classes derivas de uma
mesma classe pode ser difcil ou mesmo impraticvel criar uma nova classe
que faa uso de funcionalidades de classes existentes nesta hierarquia. Mesmo
que isto seja possvel, a proliferao de classes acabaria por criar uma
quantidade muito grande de classes com funcionalidades repetidas.
Padres de Projeto
Romualdo Rubens de Freitas 50
Builder Criao
Apresentao Este padro de projeto apropriado quando se deseja criar um produto
em partes. O cliente, utilizando um objeto builder pede que o objeto produto
seja criado. O objeto builder invoca um conjunto de mtodos que possibilita a
criao do objeto produto, que , ento, retornado. Assim, possvel que um
objeto complexo possa ser criado sem que a aplicao (cliente) tenha
conhecimento de como suas vrias partes so criadas.
Aplicabilidade Na criao de objetos complexos que devem ser montados
independentes de suas partes ou de sua montagem. Alm disto, o processo de
construo deve permitir diferentes representaes para o objeto que
construdo.
Estrutura
Descrio
O objeto Director realiza a construo de um objeto Product mediante a construo de suas vrias partes, descritas pela interface Builder e que so implementadas por ConreteBuilder.
Padres de Projeto
Romualdo Rubens de Freitas 51
Exemplo de Cdigo
Padres de Projeto
Romualdo Rubens de Freitas 52
Exemplo na API Java Entre os vrios exemplos, podem ser citadas as classes
javax.xml.parsers.DocumentBuilder e java.lang.ProcessBuilder. A primeira define uma API para obter um objeto DOM (Document Object Model) a partir de um documento XML
(eXtensible Markup Language) e a segunda possibilita a criao de processos
junto ao sistema operacional.
Observaes
Padres Relacionados Abstract Factory e Composite.
Anti-Pattern O anti-pattern deste padro de projeto lida com o problema da criao
de objetos complexos de forma aleatria e espalhada pelo cdigo. Se um novo
objeto precisa ser criado a modificao na aplicao para realizar esta nova
operao onerosa em termos de tempo e propensa incluso de erros em
cdigo que j havia sido testado e validado.
Padres de Projeto
Romualdo Rubens de Freitas 53
Template Method Comportamento
Descrio Padro de projeto cuja funo generalizar um processo, em um nvel
mais genrico, em um conjunto de passos, permitindo que etapas comuns
sejam implementadas e que etapas especficas tenham suas implementaes
realizadas por classes descendentes. Em outras palavras, este padro permite
que subclasses de uma classe comum possam variar partes de um algoritmo
mais geral.
Aplicabilidade Partes de um algoritmo genrico so implementadas em uma classe
comum a partir da qual suas subclasses podem ou devem implementar as
partes especficas.
Estrutura
Descrio
A classe AbstractClass possui o mtodo templateMethod() e as assinaturas de mtodos abstratos, usados pelo mtodo template, que devem
ser implementados por classes descendentes. Uma vez que a classe contendo
o mtodo com os passos comuns (ou genricos) tenha sido criada, vrias
classes concretas podem existir, cada uma implementando as partes
especficas do algoritmo.
Padres de Projeto
Romualdo Rubens de Freitas 54
Algumas vezes um algoritmo genrico pode-se valer de passos que, se
no implementados por classes descendentes, podem no existir ou so
padronizados. Neste caso, as classes descendentes podem escolher ou no
realizar suas implementaes.
Outras vezes, dependendo do projeto, AbstractClass pode ser, na verdade, uma classe concreta, cujos passos especficos de um algoritmo
podem ou devem ser implementadas por classes descendentes.
Exemplo de Cdigo
Exemplo na API Java
Observaes Um dos conceitos mais importantes em projetos de software trata do
reuso de cdigo e o padro de projeto Template Method fundamental neste
Padres de Projeto
Romualdo Rubens de Freitas 55
quesito, pois cdigo (passos de um algoritmo) necessrio execuo de uma
tarefa pode ser deixado a cargo de classes que tm como base uma classe
comum que realizar a tarefa.
Padres Relacionados Factory Method e Strategy.
Anti-Pattern Se o cdigo necessrio a uma tarefa composto de partes que so
especficas a determinadas situaes o programador escrever estas partes
utilizando um conjunto de if-else-if-else.... Mais uma vez, uma atitude como esta torna o cdigo final um emaranhado de condies, que continuaro a
crescer media que novas condies forem impostas como requisitos
aplicao.
Padres de Projeto
Romualdo Rubens de Freitas 56
Iterator Comportamento
Apresentao Este padro de projeto fornece uma interface comum para que uma
coleo de objetos possa ser percorrida sem, no entanto, que a aplicao tome
conhecimento de como tais objetos esto agrupados.
Aplicabilidade A utilizao deste padro de projeto possibilita aplicao ter acesso ao
contedo de um objeto agregado sem que sua representao interna seja
exposta. A coleo de objetos pode ser percorrida em ambas as direes, de
acordo com a declarao da interface.
Estrutura
Descrio
Collection a interface comum que disponibiliza a assinatura do mtodo createIterator(), entre outros, que deve ser implementado pelas classes descendentes e cujas implementaes permitem o percorrimento da
coleo de objetos (agregado). Assim, cada coleo concreta implementa o
algoritmo de percorrimento de acordo com a representao de seus dados,
retornando aplicao uma referncia interface Iterator, que apresenta uma interface comum utilizada para percorrer da coleo de objetos.
Padres de Projeto
Romualdo Rubens de Freitas 57
Exemplo de Cdigo
Exemplo na API Java
A interface Enumeration e Iterator , ambas presentes no pacote java.util, so utilizadas pelas classes de coleo para fornecer um interface comum de percorrimento de seus objetos. Alm do nome mais curto, a
interface Iterator possui um mtodo que permite a remoo de elementos da coleo.
Padres de Projeto
Romualdo Rubens de Freitas 58
Observaes
Padres Relacionados Composite, Factory Method e Memento.
Anti-Pattern Neste caso, o anti-pattern implementado diretamente na classe que
descreve a coleo de objetos, deixando que a aplicao tenha acesso
representao destes dados.
Padres de Projeto
Romualdo Rubens de Freitas 59
Composite Estrutura
Apresentao Objetos so compostos em uma estrutura semelhante a uma rvore
para representar hierarquias todo-parte. Assim, este padro de projeto permite que elementos primitivos e composies de elementos sejam tratados de forma
semelhante.
Aplicabilidade Quando se deseja modelar relaes de componentes e estes, por sua
vez, tambm so constitudos de outros componentes.
Estrutura
Descrio
A aplicao cliente faz uso de Component para ter acesso aos objetos na composio. A interface Component, por sua vez, define uma interface padro para todos os objetos na composio, tanto para elementos simples
ou primitivos (Leaf), quanto para elementos compostos (Composite). Leaf implementa os mtodos para os elementos da composio, enquanto
Composite implementa os mtodos relacionados aos elementos na composio.
Padres de Projeto
Romualdo Rubens de Freitas 60
Tanto Leaf quanto Composite implementam Component, mas, no entanto, alguns dos mtodos de Component no fazem sentido a Leaf, da mesma forma que outros no fazem sentido a Component. Neste caso, possvel realizar uma implementao padro, como lanar uma exceo, por
exemplo, nos mtodos definidos em Component. Assim, os mtodos que interessam a Leaf sero sobrescritos, da mesma forma sero sobrescritos os que interessam a Composite. Se um mtodo que no possui relao com Leaf, por exemplo, for invocado, a exceo ser lanada.
Exemplo de Cdigo
Padres de Projeto
Romualdo Rubens de Freitas 61
Exemplo na API Java
Os componentes grficos (classes) JFrame, JDialog e JPanel, disponveis no pacote javax.swing e que fazem parte da API Swing, so exemplos de componentes do tipo continer, aqueles que armazenam uma
coleo de componentes grficos, como, por exemplo, JButton e JTextField, entre outros. No caso de JPanel, alem de continer, ele tambm um componente que pode ser adicionado a um JFrame, por exemplo.
Observaes O padro de projeto Composite pode ser dividido, basicamente, em dois
grupos: Composio de Relao e Composio Taxonmica. No primeiro caso, a relao todo-parte d-se pela composio de objetos complexos feita
de objetos menores, que podem, tambm, ser compostos de objetos ainda
menores. J no segundo caso, a relao de composio existe entre objetos de
tipos que so mais ou menos gerais.
A Composio Taxonmica geralmente utilizada quando se deseja
percorrer os seus elementos, encontrar alguma informao ou processar um
Padres de Projeto
Romualdo Rubens de Freitas 62
elemento com base em algum contexto. Este processamento realizado pela
aplicao cliente.
A Composio de Relao implementada levando-se em considerao
o comportamento desejado, o que ter diferentes implicaes quanto ao
encapsulamento, que pode ser: Comportamento por Agregao cuja implementao do comportamento est vinculada ao percorrimento de todos os
elementos filhos para que se possa realizar o processamento da composio;
Comportamento Caso Melhor/Pior quando a implementao do comportamento leva em considerao o processamento dos elementos filhos e,
caso algum no satisfaa determinada condio, a composio como um todo
no a satisfar tambm; Comportamento Investigatrio caso em que a aplicao cliente realizar o percorrimento na composio, pois somente esta
saber se um determinado elemento satisfaz ou no um dado critrio.
Padres Relacionados Decorator, Flyweight, Iterator e Visitor.
Anti-Pattern No anti-pattern deste padro de projeto a composio substituda por
diversas referncias aos elementos que uma dada classe deve possuir. Para
que esta classe possa processar um novo elemento, outra referncia deve ser
acrescentada, o que, muito provavelmente, acarretar a mudana no
processamento das varias partes.
Padres de Projeto
Romualdo Rubens de Freitas 63
State Comportamento
Descrio Este padro de projeto permite que um objeto modifique seu
comportamento de acordo com a mudana de seu estado interno. Assim, tem-
se a impresso que o objeto muda sua classe.
Aplicabilidade O uso deste padro de projeto d-se quando o comportamento de um
objeto depende de seu estado e este comportamento deve se modificar em
tempo de execuo (runtime) de acordo com este estado e, tambm, quando
muitas declaraes condicionais (if-else-if-else) dependem do estado do objeto. Neste caso, cada operao, que realizada de acordo com um valor
constante, deve ser transferida para uma classe prpria. Esta transferncia
permite tratar o estado do objeto como um objeto por si s.
Estrutura
Descrio
Context pode ser qualquer classe na aplicao que contm vrios estados internos. Quando o mtodo request() invocado sobre o objeto contexto, o processamento delegado ao objeto estado (State). Assim, os estados concretos (ConcreteStateA, ConcreteStateB) tratam (manipulam) as requisies provenientes do contexto e os estados concretos tm suas
prprias implementaes para o tratamento da requisio. Desta forma,
Padres de Projeto
Romualdo Rubens de Freitas 64
quando Context muda seu estado (o(s) valor(es) de seu(s) atributo(s) (so) alterado(s)), seu comportamento tambm muda.
Exemplo de Cdigo
Exemplo na API Java
Observaes
Padres Relacionados Flyweight.
Anti-Pattern Classes com extensos cdigos condicionais para tratarem seus diversos
estados so o exemplo de anti-pattern apresentado para este padro de
projeto.
Padres de Projeto
Romualdo Rubens de Freitas 65
Strategy Comportamento
Apresentao Este padro de projeto define uma famlia de algoritmos, os encapsula e
os torna intercambiveis. Estes algoritmos podem variar independente da
aplicao cliente que os usa.
Aplicabilidade Este padro de projeto prov uma forma de configurar uma classe com
um de vrios comportamentos ou algoritmos. Alm disto, possvel esconder
da aplicao as estruturas de dados, possivelmente complexas, utilizadas
pelos diversos algoritmos. Isto permite que diferentes regras de negcios
possam ser utilizadas dependendo do contexto no qual elas ocorram,
significando que este padro de projeto fornece um meio de configurar uma
classe com um entre vrios comportamentos.
Estrutura
Descrio Encapsula algoritmos em classes, permitindo que eles possam variar
independente da aplicao cliente que os usa. Isto possibilita a aplicao do
princpio denominado Princpio Aberto-Fechado (Open-Closed Principle), no qual uma classe est aberta para extenses enquanto mantm-se fechado
para alteraes. Tal princpio alcanado pelo uso deste padro de projeto,
pois a aplicao cliente faz uso de uma classe base (classe abstrata ou
interface) e os detalhes de implementao esto presentes em classes
Padres de Projeto
Romualdo Rubens de Freitas 66
derivadas. A aplicao cliente no sofre impacto no caso do aumento de
classes derivadas, nem tampouco com eventuais mudanas que essas classes
venham a sofrer. Com isto, a aplicao cliente minimiza o acoplamento, pois
mantm um vnculo com a abstrao (classe abstrata ou interface) e no com
uma implementao especfica.
Exemplo de Cdigo
Padres de Projeto
Romualdo Rubens de Freitas 67
Exemplo na API Java
As classes CheckInputStream e CheckOutputStream, ambas presentes no pacote java.util.zip, utilizam este padro de projeto para calcular checksums4 no fluxo de bytes lidos e gravados.
Os componentes presentes na AWT (Abstract Window Toolkit), tais
como botes, menus e listas, entre outros, so posicionados em componentes
do tipo continer, como painis, janelas de dilogo e janelas, por exemplo. Este
posicionamento no realizado pelos contineres, mas sim delegado aos
gerenciadores de layout. Tal delegao um exemplo do padro de projeto
Strategy.
Observaes
Padres Relacionados Flyweight.
Anti-Pattern A utilizao de estruturas de seleo do tipo if-else-if-else-if-else...
torna a aplicao altamente acoplada ao conjunto de algoritmos que necessita
utilizar, alm de no ser possvel aplicar o Princpio Aberto-Fechado.
4 Checksums so valores produzidos por algoritmos matemticos cujo objetivo o de realizar verificao de dados.
Padres de Projeto
Romualdo Rubens de Freitas 68
Proxy Estrutura
Apresentao Este padro de projeto prov acesso controlado a outros objetos por
meio de um objeto substituto (ou procurador), denominado proxy.
Aplicabilidade Normalmente, quando uma simples referncia a um objeto no
suficiente necessitando-se de uma que seja mais sofisticada, pois o acesso ao
objeto precisa ser controlado, possivelmente, verificando se os direitos de
acesso o permitem.
Alguns tipos de proxies que podem, dependendo da situao, ser
utilizados so: Proxy Remoto, Proxy Virtual, Proxy de Proteo e Proxy de Referncia Inteligente.
Estrutura
Descrio
Tanto RealSubject quanto Proxy implementam a mesma interface, Subject, o que permite que a aplicao possa tratar objetos Proxy como se fossem objetos RealSubject. RealSubject realiza o trabalho verdadeiro, enquanto Proxy simplesmente controla o acesso a ele. O objeto Proxy mantm uma referncia a RealSubject, instanciando-o ou cuidando de sua
Padres de Projeto
Romualdo Rubens de Freitas 69
criao. Desta forma, as requisies feitas ao objeto Proxy so redirecionadas ao objeto RealSubject de forma controlada.
Exemplo de Cdigo
Exemplo na API Java
A classe java.lang.reflect.Proxy fornece mtodos para a criao de classes e instncias de proxies dinmicos, sendo a super-classe para todos
os proxies dinmicos criados por estes mtodos.
Observaes Um Proxy Remoto fornece uma referncia a um objeto localizado em
outro espao de endereamento, no mesmo computador ou em um
computador conectado rede. Normalmente, um proxy remoto utilizado em
Padres de Projeto
Romualdo Rubens de Freitas 70
tecnologias de chamadas remotas a procedimentos (ou mtodos), como
acontece com RMI (Remote Method Invocation) em Java. O Proxy Virtual possibilita a um objeto que tenha um processo de criao custoso aplicao
ser criado somente quando for necessrio. No Proxy de Proteo o acesso ao objeto real controlado e cada cliente tem um nvel diferenciado de acesso. O
Proxy de Referncia Inteligente permite controlar, por exemplo, a quantidade de referncias feitas ao objeto real.
Padres Relacionados Adapter e Decorator.
Anti-Pattern Quando a invocao de um mtodo necessita que outras aes sejam
tomadas antes que este possa efetivamente ser executado, o padro de projeto
Proxy uma boa soluo. Caso a aplicao tenha que tomar cincia (algum
processamento, como, por exemplo, verificar direitos do usurio) das aes
necessrias antes ou depois da invocao de um determinado mtodo, isto a
torna complexa, de difcil manuteno e extensibilidade se tal processamento
for implementado na aplicao cliente.
Padres de Projeto
Romualdo Rubens de Freitas 71
Visitor Comportamento
Descrio Representa uma operao que executada em uma estrutura de
objetos. Novas operaes so definidas sem, no entanto, conhecer as classes
dos objetos sobre as quais elas sero executadas.
Aplicabilidade Este padro de projeto pode ser utilizado quando uma estrutura de
objetos contm muitas classes com interfaces diferentes e se deseja executar
operaes distintas ou sem relao entre si. Isto evita a poluio de cdigo e
mantm cdigos relacionados em uma nica classe. Alm disto, normalmente a
freqncia de mudanas nas estruturas de objetos pequena, enquanto que
novas operaes podem ser acrescentadas medida que os requisitos se
modificam.
Estrutura
Padres de Projeto
Romualdo Rubens de Freitas 72
Descrio Este padro de projeto aplicado quando h necessidade de se
executar operaes semelhantes em objetos de diferentes tipos agrupados em
uma estrutura, possivelmente uma coleo. Ele tambm fornece um meio
prtico para o acrscimo de novos visitors que estendem funcionalidades pr-
existentes sem que o cdigo seja modificado.
Exemplo de Cdigo
Padres de Projeto
Romualdo Rubens de Freitas 73
Exemplo na API Java
Observaes O padro de projeto Visitor possibilita acrescentar funcionalidades a
bibliotecas de classes para as quais no h possibilidade de alterao no
cdigo fonte; obter dados de uma coleo de objetos no relacionados e
apresentar resultados de um processamento global.
Padres Relacionados Composite e Interpreter.
Anti-Pattern O anti-pattern deste padro pode levar a um cdigo rebuscado, confuso
e de difcil manuteno e extensibilidade. Como exemplo, tem-se um sistema
de vendas cujos produtos devem ser enviados aos clientes. Para que os envios
sejam processados faz-se necessrio aplicao verificar, por exemplo, por
meio do operador instanceof, qual o objeto venda sendo processado para que o envio adequado de seus produtos seja realizado. Se novas classes
representando vendas e/ou novas classes representando envios forem
acrescentadas ao sistema, a verificao apontada tornar o cdigo maior e
mais complexo.
Padres de Projeto
Romualdo Rubens de Freitas 74
Memento Comportamento
Apresentao
Este padro de projeto baseia-se em dois objetos: o objeto Originator e o objeto Caretaker. O primeiro qualquer objeto da aplicao, enquanto o segundo necessita realizar algum processamento no primeiro, mas precisa que
o estado inicial possa ser restaurado. Desta forma, o conceito de
encapsulamento no violado, o que, de outra forma, exporia aplicao os
detalhes de implementao do objeto que sofrer o processamento.
Aplicabilidade Quando se deseja realizar algum processamento temporrio em
determinado objeto da aplicao, o padro de projeto Memento aplicado de
tal forma que um instantneo (snapshot) do estado (ou de parte deste) do
objeto em questo seja salvo para ser restaurado posteriormente ao
processamento realizado.
Estrutura
Padres de Projeto
Romualdo Rubens de Freitas 75
Descrio
O objeto Caretaker deve realizar algum processamento com o objeto Originator, possivelmente mudando seu estado. Antes que isto acontea, o objeto Caretaker pede ao objeto Originator por uma referncia a Memento, realiza o processamento desejado e devolve a referncia Memento ao objeto Originator para que seu estado seja restaurado.
Exemplo de Cdigo
Padres de Projeto
Romualdo Rubens de Freitas 76
Exemplo na API Java
Observaes A implementao deste padro de projeto deve ser realizada com
cautela, pois o objeto Originator pode modificar outros objetos e este padro de projeto age sobre um nico objeto.
Padres Relacionados Command e Iterator.
Anti-Pattern Para este padro de projeto o seu anti-pattern a falta da possibilidade
de restaurao do estado do objeto com o qual se deseja realizar algum
processamento (Originator). Mesmo que a aplicao acrescente a possibilidade de restaurao de estado de um dado objeto sem a aplicao
deste padro de projeto, ainda seria o uso do anti-pattern, pois a aplicao
precisaria expor os detalhes de implementao do objeto em questo.
Padres de Projeto
Romualdo Rubens de Freitas 77
Mediator Comportamento
Apresentao Este padro de projeto prov uma interface unificada a um conjunto de
interfaces em um subsistema, fazendo com que a comunicao entre os vrios
objetos do subsistema seja realizada por um objeto. Desta forma, os objetos do
subsistema deixam de manter relaes entre si, reduzindo, assim, o
acoplamento.
Aplicabilidade A aplicabilidade para este padro de projeto d-se quando se quer
separar a comunicao que vrios objetos tm entre si atravs de uma
interface bem definida, diminuindo, assim, suas interdependncias.
Estrutura
Descrio
Objetos Colleague so desacoplados uns dos outros. As classes concretas de Colleague conversam com a implementao concreta de Mediator, que, por sua vez, conduz a troca de mensagens entre objetos Colleague.
Padres de Projeto
Romualdo Rubens de Freitas 78
Exemplo de Cdigo
Padres de Projeto
Romualdo Rubens de Freitas 79
Exemplo na API Java
Observaes Este padro de projeto, bem como os padres Chain of Responsibility,
Command e Observer realizam o desacoplamento entre objetos remetentes e destinatrios, mas com diferenas. O primeiro passa o remetente ao longo de uma cadeia de destinatrios em potencial. O segundo descreve uma conexo
entre remetente e destinatrio mediante o uso de uma subclasse. E o ltimo
especifica uma interface que realiza um alto desacoplamento entre vrios
destinatrios, que sero notificados de alguma mudana.
Padres Relacionados Faade e Observer.
Anti-Pattern O anti-pattern para este padro de projeto trata do alto acoplamento
entre classes que necessitam se relacionar entre si. A evoluo e manuteno
deste tipo de cdigo trazem uma srie de dificuldades, entre elas a leitura
impraticvel do cdigo para reconhecer quem se relaciona com quem; o
acrscimo de uma nova classe que necessita manter um relacionamento com
outras classes que j se relacionam.
Padres de Projeto
Romualdo Rubens de Freitas 80
Bridge Estrutura
Apresentao Este padro de projeto possibilita que abstraes sejam desacopladas
de suas implementaes, permitindo que ambas possam variar independentemente umas das outras. Este padro til no s quando uma
dada classe varia, mas quando o que ela faz tambm varia. Neste sentindo, a
classe em si vista como a implementao e o que ela faz como a abstrao.
Aplicabilidade Em casos quando se deseja que a implementao seja selecionada em
tempo de execuo evitando o seu vnculo com a abstrao. Quando abstrao
e implementao devem ser estendidas por meio de classes derivadas
permitindo combinar diferentes abstraes e implementaes.
Estrutura
Descrio
A relao entre Abstraction e Implementor conhecida como bridge e todos os mtodos na abstrao so implementados em funo da
implementao, pois Abstraction possui uma referncia para Implementor, e todas as classes concretas de Abstraction so declaradas em termos de Abstraction e no de Implementor.
Padres de Projeto
Romualdo Rubens de Freitas 81
Exemplo de Cdigo
Padres de Projeto
Romualdo Rubens de Freitas 82
Exemplo na API Java
Observaes Apesar de os padres de projeto State, Strategy, Bridge e, em menor
grau, Adapter terem estruturas semelhantes, eles so aplicados para a soluo
de diferentes problemas.
Padres Relacionados Abstract Factory e Adapter.
Anti-Pattern Quando uma implementao est diretamente vinculada sua abstrao
tem-se o anti-pattern para o padro de projeto Bridge, pois se novos requisitos
surgirem, tanto para a abstrao quanto para a implementao, a proliferao
de classes aumentar muito, tornado a evoluo da aplicao difcil e
trabalhosa.
Padres de Projeto
Romualdo Rubens de Freitas 83
Flyweight Estrutura
Apresentao Este padro de projeto se prope s aplicaes que necessitam de
grandes quantidades de dados, porm usando o compartilhamento de objetos,
evitando, assim, o consumo (muitas alocaes) de memria.
Aplicabilidade Aplica-se este padro de projeto quando h a necessidade de se
compartilhar um grande volume de dados. A aplicao cria os dados uma vez e
os compartilha atravs de um ou mais objetos.
Estrutura
Descrio
Flyweight declara uma interface comum a partir da qual classes concretas recebero e atuaro sobre estado extrnseco (aquele que
dependente do contexto no qual o objeto est atuando). A classe (fbrica)
FlyweightFactory cria e cuida de objetos Flyweight, que so compartilhados. Quando a aplicao requisita um objeto Flyweight, a fbrica devolve a instncia existente ou cria uma. ConcreteFlyweight implementa Flyweight para que o estado intrnseco (aquele que independente do estado no qual o objeto est atuando) possa ser armazenado, pois este objeto
deve ser compartilhado. s vezes, possvel que uma subclasse de
Flyweight no precise ser compartilhada. Neste caso,
Padres de Projeto
Romualdo Rubens de Freitas 84
UnsharedConcreteFlyweight faz este papel e comum que esta implementao tenha objetos ConcreteFlyweight como seus filhos.
Exemplo de Cdigo
Padres de Projeto
Romualdo Rubens de Freitas 85
Exemplo na API Java
A classe java.lang.String um exemplo da aplicao deste padro de projeto, pois a Mquina Virtual Java (JVM Java Virtual Machine) faz uso
do mesmo objeto String para representar cadeias de caracteres que so compostas pela mesma seqncia de caracteres, desde que no tenham sido
passadas ao construtor de java.lang.String.
Observaes Em comparao com o padro de projeto Faade, que permite que um
nico objeto represente um subsistema completo, o padro de projeto
Flyweight permite criar uma grande quantidade de pequenos objetos.
Padres Relacionados Composite, State e Strategy.
Anti-Pattern A cada processamento uma quantidade pequena de informaes
necessria sua realizao. Se a cada realizao deste processamento novos
objetos para estas informaes forem criados, a aplicao ter seu
desempenho comprometido e haver uma alta redundncia de objetos
contendo o mesmo estado.
Padres de Projeto
Romualdo Rubens de Freitas 86
Interpreter Comportamento
Apresentao Padro de projeto utilizado para modelar a gramtica para uma
linguagem especfica a um domnio de problemas.
Aplicabilidade Analisadores de expresses regulares, expresses algbricas e
partituras musicais (um dado som e sua durao), alm de linguagens de
consulta (query language) e protocolos de comunicao so exemplos da
aplicabilidade deste padro de projeto.
Estrutura
Descrio
AbstractExpression declara a operao comum a todos os elementos na rvore de sintaxe abstrata, enquanto TerminalExpression implementa tal operao para um determinado elemento terminal (que no
pode ser definido em termos de outros elementos).
NonterminalExpression implementa a mesma operao de forma que esta possa ser chamada recursivamente para cada smbolo na gramtica e
Context possui a informao que global ao interpretador. Como exemplo, tem-se, a seguir, a gramtica que define expresses regulares:
Padres de Projeto
Romualdo Rubens de Freitas 87
expresso ::= literal | alternativa | seqncia | repetio | ( expresso ) alternativa ::= expresso | expresso seqncia ::= expresso & expresso repetio ::= expresso * literal ::= a | b | c | ... { a | b | c | ... }*
Exemplo de Cdigo
Padres de Projeto
Romualdo Rubens de Freitas 88
Exemplo na API Java
Observaes Este padro de projeto bem pouco utilizado em aplicaes de um
modo geral, sendo mais usado em aplicaes especficas, nas quais se faz
necessrio a criao de uma linguagem para um determinado domnio de
aplicao.
Padres Relacionados Composite, Flyweight, Iterator e Visitor.
Anti-Pattern A definio de uma linguagem para um domnio um problema de
soluo complexa. Assim, torna-se difcil o desenvolvimento de uma aplicao
que no use este padro de projeto, visto que ele possui uma aplicao bem
especfica.
Padres de Projeto
Romualdo Rubens de Freitas 89
REFERNCIAS AntiPatterns. Acesso 27/04/2008. FREEMAN, Eric; FREEMAN, Elisabeth; BATES, Bert; SIERRA, Kathy. Head First Design Patterns OReilly: 2004. GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Design Patterns: elements of reusable object-oriented software Addison-Wesley: 1994. HOUSTON, Vince. Design Patterns Acesso 27/04/2008. LARMAN, Craig. Applying UML and Patterns: An introduction to Object-Oriented Analysis and Design and Iterative Development. 3 ed. Addison Wesley Professional: 2004.
Net Objectives The Net Objectives Pattern Repository
Acesso 27/04/2008.
PENDER, Tom. UML Bible. Indianapolis, Indiana, EUA John Wiley & Sons: 2003. SHALLOWAY, Alan; TROTT, James R.. Design Patterns Explained: a new perspective on object-oriented design Addison-Wesley: 2004. SourceMaking. AntiPatterns Acesso 27/04/2008. SourceMaking. Design Patterns Acesso 27/04/2008. Wikipedia: The Free Encyclopedia. Design pattern (computer science) Acesso 27/04/2008. Wikipedia: The Free Encyclopedia. Anti-pattern Acesso 27/04/2008. Wikipedia: The Free Encyclopedia. Padres de projeto de software Acesso 27/04/2008.
IntroduoSingleton CriaoFactory Method CriaoAbstract Factory CriaoCommand ComportamentoChain of Responsibility ComportamentoObserver ComportamentoAdapter EstruturaFaade EstruturaPrototype CriaoDecorator EstruturaBuilder CriaoTemplate Method ComportamentoIterator ComportamentoComposite EstruturaState ComportamentoStrategy ComportamentoProxy EstruturaVisitor ComportamentoMemento ComportamentoMediator ComportamentoBridge EstruturaFlyweight EstruturaInterpreter ComportamentoREFERNCIAS