Padrões de Projeto (GoF)

Srie Fundamentos da Engenharia de Software
Padres de Projetos
PINHEIRO, lvaro Farias
Autor
I
Padres de Projetos
Publicao 2017
O autor acredita que todas as informaes aqui apresentadas esto corretas e podem ser
utilizadas para qualquer fim legal. Entretanto, no existe qualquer garantia explcita ou implcita,
de que o uso de tais informaes conduzir sempre ao resultado desejado. Os nomes de sites e
empresas, por ventura, mencionados, foram utilizados apenas para ilustrar os exemplos, no
tendo vnculo nenhum com o livro, no garantindo a sua existncia nem divulgao. Eventuais
erratas estaro disponveis para download no site de publicao.
As imagens utilizadas neste livro foram obtidas na Internet.
Dados da Publicao
Pinheiro, lvaro Farias

Srie Fundamentos da Engenharia de Software: Padres de Projetos
Ano II Nmero 2 Recife, Fevereiro de 2017
Selo Editorial: Publicao Independente
1. GoF Criacional
2. GoF Estrutural
3. GoF Comportamental
II
Padres de Projetos
Publicao Independente
Revista em portugus com o ttulo
Padres de Projetos
Ano II Nmero 2
Recife Pernambuco Brasil
Fevereiro de 2017
III
Srie Fundamentos da Engenharia de Software Ano II Nmero 2 GoF
Introduo
Um padro a soluo para um determinado problema em um determinado

contexto. Um padro codifica conhecimento especfico obtido em uma
experincia em um determinado domnio. Um sistema bem estruturado estar
cheio de padres: de linguagem; de projeto; e de arquitetura. Segundo Fowler,
podem ser utilizados para melhorar o entendimento ou comunicao dos
problemas e decises arquiteturais. Podem ser vistos como uma tentativa de
criar um vocabulrio comum para comunicao.
Um padro que se deve ter conhecimento na orientao a objetos o GRASP

que significa General Responsability Assignment Software Patterns e que
descreve os princpios fundamentais do design orientado a objetos e a
atribuio de responsabilidades. Outro padro o de Gamma, et al que
descreve vinte e trs padres clssicos na orientao a objetos. O padro de
Gamma mais conhecido como padro da gangue dos quatro (Gang of Four
patterns, ou apenas GoF).
Segue um exemplo de template dos Padres de Projetos:
Nome - o nome que serve como referencia para o padro;

Problema - explica o problema que ocorre em um contexto, com sintomas
e em condies;
Soluo - elementos que constituem o design, seus relacionamentos,
responsabilidades e colaboraes;
Consequncias - resultados e compromissos decorrentes da aplicao do
padro. Impactos sobre a flexibilidade, extensibilidade, portabilidade ou
desempenho do sistema. Fundamentam a escolha do padro mais
apropriado;
Nome e Classificao - identificam unicamente o padro e o classifica para
catalogao;
Inteno - uma breve descrio que deve responder o que o padro faz
qual sua inteno e que problema ele trata;
Tambm Conhecido Como - outros nomes pelo qual o padro
conhecido;
Motivao - um cenrio que ilustra o problema e como as classes deste
padro o solucionam;
Aplicabilidade - em que situaes o padro pode ser aplicado;
Estrutura - representao grfica do padro com suas classes e
colaboraes;
Participantes - classes e objetos que participam no padro, incluindo suas
responsabilidades;
Colaboraes - como os participantes colaboram entre si;
Consequncias - como o padro atende a seus objetivos e que efeitos
colaterais seu uso pode provocar;
Implementao - dicas, tcnicas e erros comuns ao implementar este
padro;
Exemplo de Cdigo - fragmentos de cdigo ilustrando o padro;
Usos Conhecidos - exemplos de uso do padro em sistemas reais; e
Padres Relacionados - padres que esto fortemente relacionados a
este, incluindo suas diferenas, ou utilizados por este.
http://www.alvarofpinheiro.eti.br/ Pgina 1
1.1 Categorias dos Padres de Projetos
Existem basicamente trs categorias, as criacionais, estruturais e

comportamentais. Padres Criacionais: auxiliam na criao de objetos,
tornando o programa menos dependente do modo como os objetos so
criados e compostos. Assim, estes padres permitem que se mudem as
classes dos objetos criados em tempo de execuo com pouco esforo de
programao; Padres Estruturais: Descrevem formas flexveis para compor
classes e objetos; e Padres Comportamentais: Estes padres so
relacionados a algoritmos e responsabilidades associados a cada objeto.
Mudando-se os objetos e classes utilizados, pode-se mudar o comportamento
do programa. Acoplando-se um objeto a outro, pode-se adicionar
comportamento ao segundo objeto.
1.2 Critrios dos Padres de Projetos
Os padres de projeto so classificados por dois critrios, o de objetivo e o de

escopo. Objetivo reflete as categorias (criao, de estrutura ou de
comportamento). Escopo especifica quando o padro aplicado (classes ou a
objetos).
Padres com escopo de classe lidam com relacionamentos estabelecidos

atravs de herana, ou seja, estticos e definidos em tempo de compilao.
Padres com escopo de objeto lidam com relacionamentos de objeto, que
podem ser modificados em tempo de execuo e so mais dinmicos.
Praticamente todo padro utiliza herana de alguma forma, por isto apenas os
padres que focam em relacionamentos atravs de herana devem ser
classificados com escopo de classe. Os padres mais importantes esto em
escopo de objeto.
1.3 Gang of Four (GoF)
Gamma et al descrevem vinte e trs padres que podem ser utilizados em

praticamente qualquer rea de programao. Estes padres se tornaram
clssicos da orientao a objetos e so chamados de padres da gangue dos
quatro (Gang of Four patterns, ou apenas GoF). Esse padro se divide em
dois critrios: Critrio Objetivo que refletem as categorias de criao, estrutura
e comportamento, por sua vez esse critrio se divide em trs categorias.
Categoria dos Criacionais usados para determinar como os objetos so
criados; Categoria dos Estruturais que descrevem formas flexveis para
compor classes e objetos; e a Categoria dos Comportamentais relacionados
aos algoritmos e responsabilidades associados a cada objeto. O
Critrio Escopo que especifica quando o padro aplicado classe e/ou
objeto. Como pode ser visto logo abaixo.
Figura 0.1 Padres GoF

Criacional Estrutural Comportamental
1.Factory Method 1.Adapter 1.Interpreter (Classe)
(Classe) (Classe/Objeto)
2.Abstract Factory 2.Bridge (Objeto) 2.Template Method (Classe)
(Objeto)
3.Builder (Objeto) 3.Composite (Objeto) 3.Chain Responsability
(Objeto)
4.Prototype (Objeto) 4.Decorator (Objeto) 4.Command (Objeto)

5.Singleton (Objeto) 5.Facade (Objeto) 5.Strategy (Objeto)
6.Flyweight (Objeto) 6.State (Objeto)
7.Proxy (Objeto) 7.Observer (Objeto)
8.Memento (Objeto)
9.Mediator (Objeto)
10.Visitor (Objeto)
11.Iterator (Objeto)
Fonte: Prprio Autor
Descrio Resumida dos Padres GoF:
Abstract Factoty-Permitir que um cliente crie famlias de objetos sem

especificar suas classes concretas;
Adapter-Classe adaptadora entre a classe interna e um componente;
Bridge-Desassociar a evoluo de duas classes;
Builder-Encapsular a construo de um comportamento e permitir que ele
seja construdo em etapas;
Chain Responsibility-Define uma forma de passar uma solicitao entre
objetos;
Command-Encapsular um pedido de comando em um objeto;
Composite-Criar uma hierarquia parte todo;
Decorator-Estender a funcionalidade dinamicamente;
Facade-Definir uma interface de alto nvel;
Factory Method-Subclasses decidem quais classes concretas sero
criadas;
Flyweight-Definir ajustes finos em subclasses;
Interator-Fornecer forma de acessar seqencialmente uma coleo de
objetos sem expor a sua implementao;
Interpreter-Permitir a incluso de elementos de linguagem em um
aplicativo;
Mediator-Definir comunicao simplificada entre classes;
Mementor-Salvar e restaurar o estado interno de um objeto;
Observer-Definir um regime de notificao de objetos de mudanas para
um outro objeto;
Prototype-Permitir criar novas instancias simplesmente copiando
instancias existentes;
Proxy-Um classe que controla o acesso para outra classe;
Singleton-Assegurar que somente um objeto de uma determinada classe
seja criado em todo o projeto;
State-Alterar o comportamento de um objeto quando seu estado muda;
Strategy-Encapsular um algoritmo dentro de uma classe;
Template Method-Permitir que subclasses redefinam os passos de um
algoritmo; e
Visitor-Define uma nova operao em uma classe sem troc-la.
1.4 Padro de Projeto GoF Criacional
Padres criacionais so usados para determinar como os objetos sero

criados ou instanciados. Padres de projeto abstraem o processo de
instanciao. Eles ajudam a tornar o sistema independente de como os
objetos so criados, compostos e representados. Um padro criacional de
classe utiliza herana para variar a classe que ser instanciada. Um padro
criacional de objeto ir delegar a instanciao de um objeto para outro objeto.
Padres criacionais tornam-se importantes medida que os sistemas evoluem
e passam a depender mais de composio de objetos do que de herana de
classes. medida que isto acontece, a nfase migra da codificao de um
conjunto de comportamentos para a codificao de conjuntos menores de
comportamento, que podem ser combinados em vrios conjuntos mais
complexos.
1.4.1 Abstract Factory
Inteno: Prov uma interface para criar famlias de objetos relacionados ou

dependentes sem especificar suas classes concretas.
Aplicabilidade: Este padro deve ser utilizado quando o programa precisa de

independncia de como seus objetos so criados, compostos e representados.
Ou quando o sistema precise ser configurado para uma ou muitas famlias de
classes ou objetos. Ou quando uma famlia de objetos relacionados
projetada para ser utilizada em conjunto e esta premissa deve ser garantida.
Ou quando se deseja prover uma biblioteca de classes, e deseja-se
disponibilizar apenas as interfaces, e no as implementaes.
Figura 1.2 GoF Abstract Factory
Fonte: Prprio Autor
1.4.2 Builder
Inteno: Separa a construo de um objeto complexo de sua representao,

de modo que o mesmo processo de construo possa criar diferentes
representaes.
Aplicabilidade: O padro builder deve ser utilizado quando o algoritmo para

criao de objetos complexos deve ser independente das partes que
compem o objeto e da forma como este objeto montado. Ou quando o
processo de construo deve permitir diferentes representaes para o objeto
que est sendo construdo.
Figura 1.3 GoF Builder
Fonte: Prprio Autor
1.4.3 Factory Method
Inteno: Define uma interface para criao um objeto, mas deixa as

subclasses decidirem que classe instanciar. Permite que uma classe delegue a
instanciao a suas subclasses.
Aplicabilidade: Este padro deve ser utilizado quando uma classe no pode
antecipar a classe dos objetos que deve criar. Ou quando a classe deseja que
suas subclasses especifiquem o objeto que ser criado. O quando a classe
delega a responsabilidade de criao para um de muitas classes auxiliares, e
deseja-se localizar o conhecimento de que classe auxiliar deve ser delegada.
Figura 1.4 GoF Factory Method
Fonte: Prprio Autor
1.4.4 Prototype
Inteno: Especifica que tipos de objetos criarem usando uma instncia

prototpica do objeto. Cria novos objetos atravs da cpia deste prottipo.
Aplicabilidade: Este padro deve ser utilizado quando a aplicao deve ser
independente de como os produtos so criados, compostos, e representados,
e, adicionalmente: As classes a serem instanciadas so definidas em tempo
de execuo (por exemplo, dynamic loading); Deseja-se evitar criar uma
hierarquia de fbricas paralelas a hierarquia de classes; Quando a
instanciao da classe pode ter um de algumas poucas combinaes
diferentes de estado. Isto pode ser mais conveniente criar um nmero
correspondente de prottipos e clon-los ao invs de instanciar a classe
manualmente a cada vez com o estado apropriado.
Figura 1.5 GoF Prototype
Fonte: Prprio Autor
1.4.5 Singleton
Inteno: Garantir que uma classe possui apenas uma nica instncia. Prov
um ponto de acesso global a ela.
Aplicabilidade: Este padro de ser utilizado quando deve haver apenas uma
instncia de cada classe e esta instncia deve ser acessvel a todos os
clientes a partir de um ponto de acesso conhecido. Ou quando uma nica
instncia deve ser extensvel apenas por subclasses, e os clientes devem
apenas utilizar a instncia estendida, sem modificar seu cdigo.
public class Singleton {

private static Singleton instancia;
private Singleton() {
}
public static Singleton getInstancia() {
if (instancia == null)
instancia = new Singleton();
return instancia;
}
}
1.5 Padro de Projeto GoF Estrutural
Padres estruturais que descrevem as formas para relacionar as classes e

objetos. Padres estruturais focam em como criar estruturas de maior porte
atravs da composio de classes e objetos. Padres estruturais de classe
utilizam herana para compor interfaces ou implementaes. Padres
estruturais de objeto utilizam composio de objetos para prover novas
funcionalidades. A flexibilidade adicional da composio de objetos vem da
habilidade de mudar esta composio em tempo de execuo, o que
impossvel na composio esttica de classes.
1.5.1 Adapter
Inteno: Converte a interface de uma classe na interface esperada pelo

cliente. Compatibiliza classes de interfaces no compatveis, permitindo que
trabalhem em conjunto.
Aplicabilidade: Este padro deve ser utilizado quanto se deseja utilizar uma
classe j existente, e sua interface no atende a interface que voc precisa.
Quando se deseja criar uma classe reusvel que coopera com classes ainda
no conhecidas ou no criadas, ou seja, classes que no necessariamente
possui interfaces compatveis. Necessita-se usar diversas subclasses j
existentes, mas impraticvel adaptar suas interfaces atravs da criao de
subclasses para cada uma delas. Um objeto adaptador pode adaptar a
interface da superclasse.
Figura 1.6 GoF Adpater
Fonte: Prprio Autor
1.5.2 Bridge
Inteno: Desacopla uma abstrao de sua implementao, de modo que as

duas possam variar independentemente.
Aplicabilidade: Este padro pode ser utilizado nas seguintes situaes:

Deseja-se evitar uma dependncia direta entre a abstrao e sua
implementao. Este pode ser o caso, por exemplo, quando a implementao
tiver de ser selecionada ou substituda em tempo de execuo; Ambas as
abstraes e suas implementaes devem ser extensveis atravs da criao
de subclasses. Neste caso o padro bridge permite que diferentes abstraes
e implementaes possam ser combinadas e estendidas independentemente.
Mudanas na implementao de uma abstrao no deve impactar em seus
clientes, isto , seu cdigo no deve ser recompilado.
Figura 1.7 GoF Bridge
Fonte: Prprio Autor
1.5.3 Composite
Inteno: Compe objetos em estruturas de rvores para representar

hierarquias parte-todo. Permite que clientes tratem de modo uniforme tanto
objetos individuais quanto suas composies.
Aplicabilidade: Este padro deve ser utilizando quando se deseja representar

hierarquias parte-todo. Ou quando se deseja que clientes sejam capazes de
ignorar as diferenas entre composies dos objetos e os objetos
individualmente. Clientes iro tratar uniformemente todos os objetos na
estrutura composta.
Figura 1.8 GoF Composite
Fonte: Prprio Autor
1.5.4 Decorator
Inteno: Anexa dinamicamente responsabilidade adicional a um objeto. Prov

uma alternativa flexvel ao uso de herana como mecanismo de extenso de
funcionalidade.
Aplicabilidade: Utilize este padro para adicionar responsabilidades individuais

a objetos dinamicamente e transparentemente, isto , sem afetar outros
objetos. Utilize este padro para responsabilidades que podem ser
removidas. Ou ainda quando a extenso de funcionalidade atravs da
criao de subclasses impraticvel. Em algumas situaes um grande
nmero de extenses independentes possvel e isto poder produzir uma
grande quantidade de subclasses para suportar cada uma das combinaes.
Figura 1.9 GoF Decorator
Fonte: Prprio Autor
1.5.5 Facade
Inteno: Prov uma interface unificada para o conjunto de interfaces de um

subsistema. Define uma interface de mais alto nvel que torna um subsistema
de mais fcil uso.
Aplicabilidade: Utilize este padro quando: Deseja-se prover uma interface

simples para um subsistema complexo. A fachada pode prover uma viso
padro do subsistema que boa o suficiente para a maior parte dos clientes.
Apenas clientes que necessitem de customizao tero que olhar alm da
fachada. Existem muitas dependncias entre clientes e as classes que
implementam as abstraes. A introduo da fachada desacopla o subsistema
dos clientes e outros subsistemas, promovendo a independncia e
portabilidade do subsistema. Deseja-se quebrar o sistema em camadas. Utilize
a fachada para definir um ponto de entrada para cada um dos subsistemas. Se
os subsistemas so dependentes, podem-se simplificar as dependncias entre

eles fazendo com que se comuniquem apenas atravs de suas fachadas.
Figura 1.10 GoF Facade
Fonte: Prprio Autor
1.5.6 Flyweight
Inteno: Usa compartilhamento para suportar um grande nmero de

pequenos objetos de forma eficiente.
Aplicabilidade: Este padro deve ser utilizado quando: Uma aplicao utiliza
um grande nmero de objetos; Armazenamento tem custo elevado devido
grande quantidade de objetos; Muitos grupos de objeto podem ser substitudos
por relativamente poucos objetos compartilhados. A aplicao no depende da
identidade do objeto. Uma vez que os objetos podem ser compartilhados,
testes de identidade iro retornar true para objetos conceitualmente distintos.
Figura 1.11 GoF Flyweight
Fonte: Prprio Autor
1.5.7 Proxy
Inteno: Prov um ponto de atendimento para que outro objeto possa

controlar o acesso ao primeiro.
Aplicabilidade: Proxy aplicvel sempre que existe a necessidade de

referncias mais versteis ou sofisticadas que um ponteiro para um objeto.
Exemplos comuns so: Proxy remoto provendo um representante local para
um objeto em um espao de memria diferente; Proxy virtual criando objetos
custosos sobre demanda; Proxy de proteo controlando o acesso ao objeto
original; Referncia inteligente que executa aes adicionais quando o objeto

original acessado.
Figura 1.12 GoF Proxy
Fonte: Prprio Autor
1.6 Padro de Projeto GoF Comportamental
Padres comportamentais so relacionados aos algoritmos e

responsabilidades associados a cada objeto. Padres comportamentais esto
relacionados com algoritmos e atribuio de responsabilidades entre objetos.
Estes padres no descrevem apenas os padres de classes e objetos, mas
tambm os padres de comunicao entre estas classes e objetos.
Caractereizam complexos fluxos de controle, difceis de acompanhar em
tempo de execuo. Eles mudam o foco do fluxo de controle e permite que se
concentre apenas na forma como os objetos esto interconectados. Padres
comportamentais de classes utilizam herana para distribuir o comportamento
entre classes, que inclui os padres Template Method o mais simples deles,
e o Interpreter. Padres comportamentais de objetos utilizam composio de
objetos, ao invs de herana, para realizao de tarefas que um nico objeto
no poderia realizar. Estes objetos podem manter referncias explcitas entre
si, porm isto trs um maior acoplamento. Outros padres permitem um menor
nvel de acoplamento, como o Memento, Chain of Responsability e Observer.
1.6.1 Chain of Responsability
Inteno: Evita acoplamento entre solicitantes e atendentes permitindo que

mais de um objeto tenha chance de tratar a solicitao. Encadeia os
atendentes e passa a solicitao atravs desta cadeia permitindo que todos
eles a tratem.
Aplicabilidade: Este padro deve ser usado quando: mais de um objeto pode
tratar uma solicitao e o objeto que a tratar no conhecido a priori. O
objeto que trata a solicitao deve ser escolhido automaticamente; deve-se
emitir uma solicitao para um dentre vrios objetos, sem especificar
explicitamente o receptor; o conjunto de objetos que pode tratar uma
solicitao deveria ser especificado dinamicamente.
Figura 1.13 GoF Chain Responsability
Fonte: Prprio Autor
1.6.2 Template Method
Inteno: Permite subclasses redefinir os passos de um algoritmo.
Aplicabilidade: Este padro deve ser utilizado: Para implementar partes

invariantes de um algoritmo uma nica vez e deixar que as subclasses
implementem o comportamento que varia. Quando o comportamento padro
entre subclasses devam ser fatorados e localizados em uma classe comum
para evitar duplicao de cdigo; Para controlar extenses por subclasses.
Pode-se definir um template method que chama operaes gancho em pontos
especficos, permitindo extenses apenas nestes pontos.
Figura 1.14 GoF Template Method
Fonte: Prprio Autor
1.6.3 Command
Inteno: Encapsula uma solicitao em um objeto, permitindo que se

parametrize clientes com diferentes solicitaes, filas ou registros de
solicitaes, suportando ainda que operaes sejam desfeitas.
Aplicabilidade: Utilize este padro para: Parametrizar objetos por uma ao a

ser executada. Voc pode expressar tal parametrizao numa linguagem
procedural atravs de uma funo callback, ou seja, uma funo que
registrada em algum lugar para ser chamada em um momento mais adiante.
Os Commands so uma substituio orientada a objetos para callbacks;
Especificar, enfileirar e executar solicitaes em tempos diferentes. Um objeto
Command pode ter um tempo de vida independente da solicitao original. Se
o receptor de uma solicitao pode ser representado de uma maneira
independente do espao de endereamento, ento voc pode transferir um
objeto Command para a solicitao para um processo diferente e l atender a
solicitao; Suportar desfazer operaes. A operao Execute, de Command,
pode armazenar estados para reverter seus efeitos no prprio comando. A
interface do Command deve ter acrescentada uma operao Unexecute, que o

reverte efeitos de uma chamada anterior de Execute. Os comandos
executados so armazenados em uma lista histrica. O nvel ilimitado de
desfazer e refazer operaes so obtidos percorrendo esta lista para trs e
para frente, chamando operaes Unexecute e Execute, respectivamente.
Figura 1.15 GoF Command
Fonte: Prprio Autor
1.6.4 Strategy
Inteno: Encapsular um algoritmo dentro de uma classe.
Aplicabilidade: Este padro deve ser utilizando quando: Diversas classes

relacionados diferem apenas em comportamento. Estratgias provem formas
de configurar a classe com um dos muitos comportamentos; Necessita-se de
diversas variaes de um algoritmo; Um algoritmo utiliza dados que no
devem ser conhecidos pelo cliente. Utilize este padro para evitar expor
estruturas de dados complexas e especficas do algoritmo. Um classe define
diversos comportamentos, e estes aparecem como instrues condicionais
mltiplas. Ao invs de manter estas condicionais, mova os trechos
condicionais para sua prpria classe de estratgia.
Figura 1.16 GoF Strategy
Fonte: Prprio Autor
1.6.5 State
Inteno: Alterar o comportamento de um objeto quando seu estado muda.
State Aplicabilidade: Este padro deve ser utilizado quando: O comportamento

de um objeto depende fortemente do seu estado e ele deve alterar o seu
comportamento em tempo de execuo dependendo do seu estado. Os

mtodos tm instrues condicionais grandes em que as condies dependem
do estado do objeto. Este estado normalmente representado por uma ou
mais constantes do tipo enumerado. Frequentemente, vrios mtodos contm
esta mesma estrutura condicional. O padro State coloca cada ramo da
instruo condicional numa classe separada. Desta forma, o estado do objeto
pode ser tratado como um objeto ele prprio, o qual pode variar
independentemente.
1.6.6 Observer
Inteno: Define um regime de notificao de objetos de mudanas para outro

objeto.
Aplicabilidade: Use este padro quando uma mudana em um objeto deve

causar mudana em outros e no se sabem quais e quantos so os outros
objetos; quando um objeto deve ser capaz de notificar outros objetos sem
assumir nada sobre que so estes outros objetos. Em outras palavras, voc
no quer que estes objetos estejam fortemente acoplados entre si.
Figura 1.17 GoF Observer
Fonte: Prprio Autor
1.6.7 Interpreter
Inteno: Dada uma linguagem, cria uma representao de sua gramtica,

juntamente com um interpretador que utiliza esta representao para
interpretar sentenas na linguagem.
Aplicabilidade: Este padro deve ser utilizado quando existe uma linguagem a
ser interpretada e possvel representar expresses nesta linguagem como
rvores sintticas abstratas. Esse padro funciona melhor quando: A
gramtica simples. Para gramticas complexas, a hierarquia de classes se
torna muito grande e no gerencivel. Outras ferramentas como geradores de
parsers so melhores alternativas nestas situaes, pois podem interpretar
expresses sem construir rvores sintticas abstradas, o que pode salvar
espao e possivelmente tempo; Eficincia no crtico. Os interpretadores
mais eficientes so usualmente no implementados atravs da interpretao
de rvores de parser diretamente, mas primeiro feita uma traduo para um
outro formato.
Figura 1.18 GoF Interpreter
Fonte: Prprio Autor
1.6.8 Memento
Inteno: Salvar e restaurar o estado interno de um objeto.
Aplicabilidade: Use este padro quando uma parte ou todo o estado de um

objeto deve ser guardado e possivelmente recuperado posteriormente; a
obteno direta do estado quebraria a proteo de informao expondo
detalhes de implementao.
1.6.9 Mediator
Inteno: Define um objeto que encapsula o modo como um conjunto de

objetos interage. Promove um acoplamento fraco entre objetos, evitando que
referenciem explicitamente um ao outro, e com isto permitindo que se possa
variar independentemente a interao entre eles.
Aplicabilidade: Use este padro quando um conjunto de objetos se comunica

de maneira complexa; o reuso de objetos dificultado porque este referencia e
se comunica com muitos outros objetos; o comportamento operaes deve ser
customizvel sem a criao de inmeras subclasses.
Figura 1.19 GoF Mediator
Fonte: Prprio Autor
1.6.10 Visitor
Inteno: Define uma nova operao em uma classe sem troc-la.
Aplicabilidade: Este padro deve ser utilizado quando: Uma estrutura de

objetos contm muitas classes de objetos com interfaces distintas, e deseja-se
executar operaes nestes objetos que dependem de sua classe concreta;
Muitas operaes distintas e no relacionadas precisam ser executadas em
objetos em uma estrutura de objetos, e deseja-se evitar poluir estas classes
com estas operaes. Visitor permite que operaes relacionadas sejam
mantidas juntas definindo-as em uma classe. Quando a estrutura do objeto
compartilhada por muitas aplicaes, utilize Visitor para colocar as operaes
apenas nas aplicaes que necessitem dela; As classes que definem a
estrutura do objeto raramente mudam, porm frequentemente deseja-se
adicionar novas operaes sobre a estrutura. Modificar a classe da estrutura
de objetos requer redefinir a interface para todos os visitors, o que
potencialmente custoso. Se as classes da estrutura de objetos mudam
constantemente, provavelmente melhor definir as operaes nestas classes.
Figura 1.20 GoF Visitor
Fonte: Prprio Autor
1.6.11 Iterator
Inteno: Prov uma forma de acessar seqencialmente os elementos de um

agregado de objetos, sem expor a sua representao interna.
Aplicabilidade: O padro iterator deve ser utilizado para acessar agregaes

de objetos sem expor sua representao interna; para suportar diversas
varreduras transversais em agregados de objetos; para prover uma interface
uniforme para varrer estruturas agregadas diferentes.
Livros da srie Fundamentos da Engenharia de Software

Fundamentos da Introduo Este livro sobre
Engenharia de Banco de Dados. processos de
Software: Neste so desenvolvimento
Conceitos abordados os de software,
Bsicos uma conceitos bsicos evidenciando a
coletnea de de bancos de necessidade de
disciplinas que dados e seus qualidade na
integradas sistemas construo de
servem para gerenciadores, sistemas,
fundamentar o mas com o foco conceituando a
entendimento da construo de na arquitetura relacional, porque diferena entre desenvolvimento
projetos de software com qualidade, ainda hoje o mercado faz uso em Adhoc e com processo. Para isso
isto , baseado em processos larga escala desses bancos de realizado a introduo engenharia
maduros e reconhecidos pela dados, mesmo que o paradigma de requisitos abordando as tcnicas
comunidade tecnolgica. O objetivo predominante seja o orientado a para a elicitao de requisitos que
deste livro fornecer ao leitor as objetos e que, j existam a um bom forneam subsdios necessrios para
bases necessrias para o tempo bancos orientados a objeto, uma construo de software com
desenvolvimento de aplicaes at mesmo os bancos objetos- maior qualidade, enfatizando a
sejam Desktop, Web ou Mobile. relacionais que so um hibrido entre necessidade de se aplicar na
Iniciando a leitura na Teoria da essas duas arquiteturas, o que construo de qualquer sistema as
Computao, passando por predomina ainda o relacional, tcnicas de anlise e modelagem,
Processos, Linguagens, Bancos de assim, este material focado na evidenciando o uso da linguagem da
Dados e finalizando com Sistemas linguagem de consulta estruturada Linguagem de Modelagem Unificada
de Informao e Colaborao. para os SGBD-Rs do mercado, com (UML) para diagramar um projeto de
Este livro pode ser lido captulo a foco na comparao de cinco dos software, explicando a necessidade
captulo ou somente a disciplina mais utilizados bancos relacionais, do uso de modelos na construo,
desejada, pois sua elaborao os quais so: Oracle, SQLServer, entrando com detalhes na anlise
consiste na compilao das MySQL, SQLBase e Interbase. orientada a objetos, com o objetivo
disciplinas fundamentais da de explorar os seus conceitos de
Engenharia de Software que so requisitos e modelagem integrados.
independentes, mas ao mesmo Este material finalizado com a
tempo se integram objetivando o introduo medidas de esforo de
desenvolvimento de aplicaes. desenvolvimento, tcnica necessria
parar responder as perguntas
bsicas de qualquer
desenvolvimento: Qual o prazo e
custo? E para responder a essas
questes abordado o uso da
mtrica anlise de ponto de funo.
Este livro aborda A motivao Este livro o

os sistemas que deste livro resultado do uso
so classificados exemplificar os da ferramenta MS
como informao, conceitos de Project da
a exemplo, Padres de Microsoft utilizada
sistemas de apoio Projetos utilizando na aplicao dos
a deciso, a linguagem de conceitos de
sistemas programao gesto de projetos
estratgicos, Java, sendo a do PMBOK com
sistemas construo uma as premissas da
gerenciais e sistemas transacionais. compilao das aulas produzidas engenharia de testes para aquisio
A produo deste material que com o intudo de facilitar o de qualidade nos produtos de
compe o volume 4 da coleo entendimento do assunto abordando software.
Fundamentos da Engenharia de os seguintes temas: Paradigma
Software resultado da compilao Orientado a Objetos que introduz o
das aulas produzidas nas disciplinas leitor nos conceitos do POO;
que compem os captulos deste Linguagem de Modelagem Unificada
livro. para apresentar a simbologia UML
dos conceitos de POO; Linguagem
de Programao Java apresentando
essa poderosa linguagem de
programao orientada a objetos
para exemplificar os padres de
projeto; e Padres de Projetos que
neste livro aborda os mais
referenciados nas academias, sendo
eles o GRASP e GoF.
Este livro aborda Este livro introduz

basicamente os nas tecnologias
conceitos bsicos Web abordando
de programao os conceitos
como autmatos, bsicos para
tipos de desenvolvimento
linguagens, para Internet com
princpios dos a apresentao
compiladores, da plataforma Dot
paradigmas de Net e exibindo
desenvolvimento e lgica de dicas de codificao para a
programao. linguagem de marcao ASPX, para
a linguagem de script mais utilizada
pelos navegadores o JavaScript com
exemplos de CSS e principalmente
dicas de cdigo para a linguagem de
programao CSharp e de banco de
dados SQL com foco no SQLServer.
.

Padrões de Projeto (GoF)

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Padrões de Projeto (GoF)

Caricato da

Copyright:

Formati disponibili

Srie Fundamentos da Engenharia de Software

As imagens utilizadas neste livro foram obtidas na Internet.

Pinheiro, lvaro Farias

Um padro a soluo para um determinado problema em um determinado

Um padro que se deve ter conhecimento na orientao a objetos o GRASP

Segue um exemplo de template dos Padres de Projetos:

Nome - o nome que serve como referencia para o padro;

1.1 Categorias dos Padres de Projetos

Existem basicamente trs categorias, as criacionais, estruturais e

1.2 Critrios dos Padres de Projetos

Os padres de projeto so classificados por dois critrios, o de objetivo e o de

Padres com escopo de classe lidam com relacionamentos estabelecidos

1.3 Gang of Four (GoF)

Gamma et al descrevem vinte e trs padres que podem ser utilizados em

Figura 0.1 Padres GoF

4.Prototype (Objeto) 4.Decorator (Objeto) 4.Command (Objeto)

Descrio Resumida dos Padres GoF:

Abstract Factoty-Permitir que um cliente crie famlias de objetos sem

1.4 Padro de Projeto GoF Criacional

Padres criacionais so usados para determinar como os objetos sero

1.4.1 Abstract Factory

Inteno: Prov uma interface para criar famlias de objetos relacionados ou

Aplicabilidade: Este padro deve ser utilizado quando o programa precisa de

Figura 1.2 GoF Abstract Factory

Fonte: Prprio Autor

Inteno: Separa a construo de um objeto complexo de sua representao,

Aplicabilidade: O padro builder deve ser utilizado quando o algoritmo para

Figura 1.3 GoF Builder

Fonte: Prprio Autor

1.4.3 Factory Method

Inteno: Define uma interface para criao um objeto, mas deixa as

Figura 1.4 GoF Factory Method

Fonte: Prprio Autor

Inteno: Especifica que tipos de objetos criarem usando uma instncia

Figura 1.5 GoF Prototype

Fonte: Prprio Autor

public class Singleton {

1.5 Padro de Projeto GoF Estrutural

Padres estruturais que descrevem as formas para relacionar as classes e

Inteno: Converte a interface de uma classe na interface esperada pelo

Figura 1.6 GoF Adpater

Fonte: Prprio Autor

Inteno: Desacopla uma abstrao de sua implementao, de modo que as

Aplicabilidade: Este padro pode ser utilizado nas seguintes situaes:

Figura 1.7 GoF Bridge

Fonte: Prprio Autor

Inteno: Compe objetos em estruturas de rvores para representar

Aplicabilidade: Este padro deve ser utilizando quando se deseja representar

Figura 1.8 GoF Composite

Fonte: Prprio Autor

Inteno: Anexa dinamicamente responsabilidade adicional a um objeto. Prov

Aplicabilidade: Utilize este padro para adicionar responsabilidades individuais

Figura 1.9 GoF Decorator

Fonte: Prprio Autor

Inteno: Prov uma interface unificada para o conjunto de interfaces de um

Aplicabilidade: Utilize este padro quando: Deseja-se prover uma interface

os subsistemas so dependentes, podem-se simplificar as dependncias entre

Figura 1.10 GoF Facade

Fonte: Prprio Autor

Inteno: Usa compartilhamento para suportar um grande nmero de

Figura 1.11 GoF Flyweight

Fonte: Prprio Autor

Inteno: Prov um ponto de atendimento para que outro objeto possa

Aplicabilidade: Proxy aplicvel sempre que existe a necessidade de