Padrões GoF: Catálogo de Padrões de Projeto

Ministrio da Educao
Universidade Tecnolgica Federal do Paran

Campus Medianeira
Padres de Projeto v3: Catlogo GoF
Romualdo Rubens de Freitas

romualdo@utfpr.edu.br
Padres de Projeto
Licena
O uso deste material est condicionado licena Creative Commons AttributionNonCommercial-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.
ii
Padres de Projeto
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
iii
Padres de Projeto
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.
iv
Padres de Projeto
Criao
Escopo
Propsito
Estrutural
Comportamental
Interpreter
Classe Factory Method Adapter (classe)
Template Method
Chain of Responsibility
Adapter (objeto) Command
Bridge
Iterator
Abstract Factory
Composite
Mediator
Builder
Objeto
Decorator
Memento
Prototype
Faade
Observer
Singleton
Flyweight
State
Proxy
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 exemplos 1, 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.
Os exemplos apresentados no livro esto escritos na linguagem Smalltak e C++.
Padres de Projeto
Nome e Classificao
Inteno
Conhecido como
Motivao
Aplicabilidade
Estrutura
Participantes
Colaboraes
Conseqncias
Implementao
Exemplo
Usos Conhecidos
Padres Relacionados
O nome descreve a essncia do padro e a

classificao reflete as divises apresentadas na
Tabela 1.
Uma breve declarao sobre o objetivo do padro,
sua lgica e inteno e a que questo de projeto
ou problema ele resolve.
Outros nomes, caso existam, pelos quais o padro
conhecido.
Apresenta uma cenrio que ilustra um problema de
projeto e como as estruturas de classes e objetos
no padro resolvem o problema.
Situaes nas quais o padro aplicvel,
exemplos de projetos ruins que o padro pode
resolver e como reconhecer tais situaes.
Apresenta a representao grfica das classes
usando uma notao baseada na OMT (Object
Modeling Technique), entre outras.
Classes e/ou objetos que participam no padro e
suas responsabilidades.
Como os participantes colaboram para conduzir
suas responsabilidades.
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.
Que cuidados, dicas e tcnicas devem ser
utilizadas quando o padro for implementado e se
h questes especficas a uma determinada
linguagem.
Fragmentos de cdigo de como o padro pode ser
implementado.
Exemplos do padro em sistemas reais.
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
vi
Padres de Projeto
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.
vii
Padres de Projeto
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
viii
Padres de Projeto
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
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
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:
10
Padres de Projeto
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.
11
Padres de Projeto
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
classe
Singleton
atravs
do
mtodo
getInstance(), que ser invocado para a obteno desta referncia.
12
Padres de Projeto
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()
13
Padres de Projeto
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 tcnica 2 o sincronismo acontece somente
se a instncia ainda no foi criada:
Alguns autores consideram esta tcnica como um padro.
14
Padres de Projeto
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:
15
Padres de Projeto
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.
16
Padres de Projeto
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
17
Padres de Projeto
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.
18
Padres de Projeto
Exemplo de Cdigo
19
Padres de Projeto
20
Padres de Projeto
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.
21
Padres de Projeto
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
22
Padres de Projeto
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
23
Padres de Projeto
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.
24
Padres de Projeto
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.
25
Padres de Projeto
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
26
Padres de Projeto
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
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
27
Padres de Projeto
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
28
Padres de Projeto
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.
29
Padres de Projeto
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.
30
Padres de Projeto
Exemplo de Cdigo
31
Padres de Projeto
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).
32
Padres de Projeto
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-Controlador 3 (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
Alguns autores consideram o MVC como um padro de projetos.
33
Padres de Projeto
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
34
Padres de Projeto
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
35
Padres de Projeto
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.
36
Padres de Projeto
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
37
Padres de Projeto
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
38
Padres de Projeto
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.
39
Padres de Projeto
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
40
Padres de Projeto
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.
41
Padres de Projeto
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.
42
Padres de Projeto
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).
43
Padres de Projeto
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.
44
Padres de Projeto
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.
45
Padres de Projeto
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
46
Padres de Projeto
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
47
Padres de Projeto
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
48
Padres de Projeto
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

FileInputStream("receitas.doc")));
InputStreamReader(new
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.
49
Padres de Projeto
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.
50
Padres de Projeto
Exemplo de Cdigo
51
Padres de Projeto
Exemplo na API Java

Entre
os
vrios
exemplos,
podem
javax.xml.parsers.DocumentBuilder
ser
citadas
as
classes
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.
52
Padres de Projeto
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.
53
Padres de Projeto
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
54
Padres de Projeto
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.
55
Padres de Projeto
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.
56
Padres de Projeto
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.
57
Padres de Projeto
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.
58
Padres de Projeto
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.
59
Padres de Projeto
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
60
Padres de Projeto
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
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
61
Padres de Projeto
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
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.
62
Padres de Projeto
State Comportamento
Descrio
Este padro de projeto permite que um objeto modifique seu
comportamento de acordo com a mudana de seu estado interno. Assim, temse 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,
63
Padres de Projeto
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.
64
Padres de Projeto
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
65
Padres de Projeto
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
66
Padres de Projeto
Exemplo na API Java

As classes CheckInputStream e CheckOutputStream, ambas
presentes no pacote java.util.zip, utilizam este padro de projeto para
calcular checksums 4 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.
Checksums so valores produzidos por algoritmos matemticos cujo objetivo o de realizar verificao de dados.
67
Padres de Projeto
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
68
Padres de Projeto
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
69
Padres de Projeto
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.
70
Padres de Projeto
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
71
Padres de Projeto
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 prexistentes sem que o cdigo seja modificado.
Exemplo de Cdigo
72
Padres de Projeto
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.
73
Padres de Projeto
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
74
Padres de Projeto
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
75
Padres de Projeto
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.
76
Padres de Projeto
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.
77
Padres de Projeto
Exemplo de Cdigo
78
Padres de Projeto
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.
79
Padres de Projeto
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.
80
Padres de Projeto
Exemplo de Cdigo
81
Padres de Projeto
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.
82
Padres de Projeto
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,
83
Padres de Projeto
UnsharedConcreteFlyweight faz este papel e comum que esta

implementao tenha objetos ConcreteFlyweight como seus filhos.
Exemplo de Cdigo
84
Padres de Projeto
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.
85
Padres de Projeto
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:
86
Padres de Projeto
expresso ::= literal | alternativa | seqncia |

repetio | ( expresso )
alternativa ::= expresso | expresso
seqncia ::= expresso & expresso
repetio ::= expresso *
literal ::= a | b | c | ... { a | b | c | ... }*
Exemplo de Cdigo
87
Padres de Projeto
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.
88
Padres de Projeto
REFERNCIAS
AntiPatterns. <http://www.antipatterns.com/> 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.
Acesso 27/04/2008.
Design Patterns
<http://www.vincehuston.org/dp/>
LARMAN, Craig. Applying UML and Patterns: An introduction to ObjectOriented Analysis and Design and Iterative Development. 3 ed. Addison
Wesley Professional: 2004.
Net
Objectives
The
Net
Objectives
Pattern
Repository
<http://www.netobjectivesrepository.com/> 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 <http://sourcemaking.com/antipatterns/> Acesso
27/04/2008.
SourceMaking. Design Patterns <http://sourcemaking.com/design_patterns/>
Acesso 27/04/2008.
Wikipedia: The Free Encyclopedia. Design pattern (computer science)
<http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29>
Acesso 27/04/2008.
Wikipedia:
The
Free
Encyclopedia.
<http://en.wikipedia.org/wiki/Anti-pattern> Acesso 27/04/2008.
Anti-pattern
Wikipedia: The Free Encyclopedia.

Padres de projeto de software
<http://pt.wikipedia.org/wiki/Padr%C3%B5es_de_projeto_de_software> Acesso
27/04/2008.
89

Padrões GoF: Catálogo de Padrões de Projeto

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Padrões GoF: Catálogo de Padrões de Projeto

Hochgeladen von

Copyright:

Verfügbare Formate

Ministrio da Educao

Universidade Tecnolgica Federal do Paran

Padres de Projeto v3: Catlogo GoF

Romualdo Rubens de Freitas

Resumidamente, com este material possvel realizar:

Criao de obras derivadas.

Tendo em mente as seguintes condies:

proibido o uso deste material com fins financeiros;

Romualdo Rubens de Freitas

Independente de opinies fica claro que a utilizao de boas prticas em

Os padres de projeto permitem a reusabilidade de projetos e

Romualdo Rubens de Freitas

forma, um padro de projeto nomeia, abstrai e identifica aspectos chave de

Padres de projeto possibilitam aplicar solues a problemas freqentes,

Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides organizam

Romualdo Rubens de Freitas

Tabela 1: Classificao dos Padres de Projeto.

Esta classificao tornou-se conhecida como Catlogo GoF, sendo que

Quando se fala em projeto de software uma notao grfica para

Os exemplos apresentados no livro esto escritos na linguagem Smalltak e C++.

Romualdo Rubens de Freitas

O nome descreve a essncia do padro e a

Alm da descrio textual e outras j citadas apresentada por Erich

Romualdo Rubens de Freitas

padro informado qual o seu propsito se de criao, estrutural ou

Assim, este material proporciona ao leitor informaes sobre Padres de

Romualdo Rubens de Freitas

Romualdo Rubens de Freitas

Alm de vrios conceitos e princpios que so empregados no projeto de

Algumas questes devem ser levadas em considerao quando se

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

A coeso mede quo bem as partes de um objeto suportam o mesmo

Romualdo Rubens de Freitas

executando mltiplas tarefas, por exemplo, ou nem todas as suas partes

Quando uma classe projetada para realizar uma determinada tarefa,

relacionados ao seu propsito, dados tambm no relacionados possivelmente

Infelizmente, altos nveis de coeso so difceis de serem obtidos, nem

O acoplamento mede o grau de dependncia entre objetos. Se um

Em outras palavras, o acoplamento trata dos relacionamentos e

A dependncia entre objetos medida sob quatro aspectos dos

Romualdo Rubens de Freitas

O nmero de associaes: cada associao que uma classe

O volume de comunicao: enquanto um objeto se comunica ele

A complexidade da comunicao: mesmo que haja pouca

Um objeto necessita conhecer da estrutura interna ou o estado

Promover uma alta coeso e um baixo acoplamento o objetivo de todo

Romualdo Rubens de Freitas

getInstance(), que ser invocado para a obteno desta referncia.

Romualdo Rubens de Freitas

Exemplo na API Java

public synchronized static Singleton getInstance()

Romualdo Rubens de Freitas

O sincronismo de mtodos faz com que a aplicao perca desempenho,

Uma alternativa criar a instncia da classe assim que ela carregada

Outra opo para minimizar o impacto no uso de threads denominada

Alguns autores consideram esta tcnica como um padro.

Romualdo Rubens de Freitas

Esta tcnica pode apresentar problemas devido otimizao realizada

Romualdo Rubens de Freitas

O que acontece neste caso que a classe interna (inner class)