Apostila Padrões de Software

Padres de Projeto de Software 0
PADRO ES DE
PROJETOS DE
SOFTWARE
Apostila
Jorge Juan Zavaleta Gavidia
Rio de Janeiro, fevereiro de 2013
PADRES DE PROJETOS DE SOFTWARE
Jorge Juan Zavaleta Gavidia
zavaleta.jorge@gmail.com
zavaleta@cos.ufrj.br

Termo de Uso

Todo o contedo desta apostila propriedade de J orge Zavaleta. A apostila pode ser
utilizada livremente para estudo pessoal. Alm disso, este material didtico pode ser
utilizado como material de apoio em cursos de ensino superior desde que seja citado
explicitamente o proprietrio do material assim como o livro E. Gamma, R. Helm, R.
Johnson, and J. Vlissides. Padres de Projetos: Solues reutilizveis de software
orientado a objetos. Porto Alegre - RS: Bookman, 2000.
proibida qualquer utilizao desse material que no se enquadre nas condies acima
sem o prvio consentimento formal, por escrito do autor. O uso indevido est sujeito s
medidas legais cabveis.

Jorge Zavaleta

INDCE
1. INTRODUO ........................................................................................................ 1
1.1 O PARADIGMA DE ORIENTAO A OBJ ETOS ............................................... 1
1.1.1 Classes ................................................................................................................. 2
1.1.2 Objetos ................................................................................................................. 3
1.1.3 Herana ................................................................................................................ 4
1.1.4 Polimorfismo........................................................................................................ 5
1.2 A UML A Linguagem de Modelagem Unificada (Unified Modeling Language) ... 6
1.2.1 Classes ................................................................................................................. 6
1.2.2 Objetos ................................................................................................................. 7
1.2.3 Estados ................................................................................................................. 8
1.2.4 Pacotes ................................................................................................................. 8
1.2.5 Relacionamentos .................................................................................................. 9
1.2.5.1 Associaes ..................................................................................................... 10
1.2.5.2 Generalizaes ................................................................................................ 13
1.2.5.3 Dependncias e Refinamentos ......................................................................... 15
1.2.6 Mecanismos Gerais ............................................................................................ 16
1.3 PADRES DE PROJ ETOS DE SOFTWARE ....................................................... 17
1.4 O QUE UM PADRO DE PROJETO? ............................................................. 18
1.5 COMO DESCREVER UM PADRO DE PROJ ETO ........................................... 19
1.6 PRINCIPAIS PADRES DE PROJ ETO ............................................................... 20
1.6.1 Finalidade dos 23 padres: ................................................................................. 20
1.6.2 Como selecionar um padro? .............................................................................. 23
2. PADRES GoF ...................................................................................................... 24
2.1 PADRES DE CRIAO .................................................................................... 24
2.1.1 Padro Abstract Factory ..................................................................................... 24
2.1.2 Padro Builder ................................................................................................... 29
2.1.3 Padro Factory Method ...................................................................................... 32
2.1.4 Padro Prototype ................................................................................................ 36
2.1.5 Padro Singleton ................................................................................................ 40
2.2 PADRES ESTRUTURAIS ................................................................................. 43
2.2.1 Padro Adapter ................................................................................................... 43
2.2.2 Padro Bridge..................................................................................................... 47
2.2.3 Padro Composite .............................................................................................. 51
2.2.4 Padro Decorator ................................................................................................ 56
2.2.5 Padro Faade .................................................................................................... 59
2.2.6 Padro Flyweight ............................................................................................... 62
2.2.7 Padro Proxy ...................................................................................................... 66
2.3 PADRES COMPORTAMENTAIS ..................................................................... 70
2.3.1 Padro Chain of Responsability .......................................................................... 70
2.3.2 Padro Command ............................................................................................... 74
2.3.3 Padro Interpreter ............................................................................................... 78
2.3.4 Padro Iterator .................................................................................................... 82
2.3.5 Padro Mediator ................................................................................................. 86
2.3.6 Padro Memento ................................................................................................ 90
2.3.7 Padro Observer ................................................................................................. 93
2.3.8 Padro State ....................................................................................................... 96
2.3.9 Padro Strategy .................................................................................................. 99
2.3.10 Padro Template Method ................................................................................ 103
2.3.11 Padro Visitor ................................................................................................ 105
3. PADRES GRASP ............................................................................................... 111
4. ARQUITETURA EM CAMADAS ....................................................................... 112
REFERNCIAS ....................................................................................................... 113

Jorge Zavaleta, 2013 zavaleta.jorge@gmail.com
1. INTRODUO
Nesta seo apresenta-se uma introduo a um dos mtodos de desenvolvimento de
software baseado em padres (os detalhes e as melhores prticas aprendidas por
projetistas e usurios ao longo dos anos) e se apresenta os conceitos bsicos que
permeiam o uso das tcnicas de orientao a objetos na programao, sempre utilizando
a linguagem J ava como motivador e a linguagem de modelagem (UML) que o suporta.
1.1 O PARADIGMA DE ORIENTAO A OBJ ETOS
Uma das atividades mais interessantes em Informtica certamente a busca
constante de melhorias nas linguagens e tcnicas para o desenvolvimento de software.
Desta busca decorrem as transformaes e evolues das linguagens de programao,
surgindo novas linguagens e novos paradigmas.
A Programao Orientada a Objetos (POO) utiliza os conceitos que aprendemos no
jardim de infncia: objetos e atributos, todos e partes, classes e membros. difcil
explicar por que demoramos tanto a aplicar estes conceitos anlise e especificao de
sistemas de informaes - talvez porque estivssemos ocupados demais olhando o auge
da anlise estruturada para imaginar que havia alternativas.
Na compreenso do mundo real, as pessoas empregam constantemente trs mtodos
de organizao, sempre presentes em todos os seus pensamentos:
1. Diferenciao, baseado na experincia de cada um, de objetos particulares e seus
atributos - quando distinguem uma rvore, e seu tamanho ou relaes espaciais,
dos outros objetos;
2. Distino entre objetos como um todo e entre suas partes componentes, por
exemplo, quando separam uma rvore dos seus galhos; e
3. Formao de, e distino entre, as diferentes classes de objetos - por exemplo,
quando formam uma classe de todas as rvores, outra classe de todas as rochas e
distinguem-nas.
Programao Orientada a Objetos a programao implementada pelo envio de
mensagens a objetos. Cada objeto ir responder s mensagens conhecidas por este, e
cada objeto poder enviar mensagens a outros, para que sejam atendidas, de maneira
que ao final do programa, todas as mensagens enviadas foram respondidas, atingindo-se
o objetivo do programa. Programao Orientada a Objetos, tcnicas e artefatos ditos
orientados a objetos incluem linguagens, sistemas, interfaces, ambientes de
desenvolvimento, bases de dados, etc.
O paradigma de orientao a objetos centrado no conceito de objeto. Tudo esta
focado nele. Escrevo cdigo organizado em torno de objetos, no de funes
(SHALLOWAY e TROTT, 2004). Objetos so instncias de classes, que determinam
qual informao um objeto contm e como ele pode manipul-la.

Um dos grandes diferenciais da programao orientada a objetos em relao a
outros paradigmas de programao que tambm permitem a definio de estruturas e
operaes sobre as mesmas esto no conceito de herana, mecanismo atravs do qual
as definies existentes podem ser facilmente estendidas. J untamente com a herana
deve ser enfatizada a importncia do polimorfismo, que permite selecionar
funcionalidades que um programa ir utilizar de forma dinmica, durante sua execuo.
1.1.1 Classes
A definio de classes e seus inter-relacionamentos o principal resultado da etapa
de projeto de software. Em geral, esse resultado expresso em termos de alguma
linguagem de modelagem, tal como UML.
Uma classe um gabarito para a definio de objetos. Atravs da definio de uma
classe, descreve-se que propriedades ou atributos que o objeto ter. Alm da
especificao de atributos, a definio de uma classe descreve tambm qual o
comportamento de objetos da classe, ou seja, que funcionalidades podem ser aplicadas a
objetos da classe. Essas funcionalidades so descritas atravs de mtodos. Um mtodo
nada mais que o equivalente a um procedimento ou funo, com a restrio que ele
manipula apenas suas variveis locais e os atributos que foram definidos para a classe.
Uma vez que estejam definidas quais sero as classes que iro compor uma
aplicao, assim como qual deve ser sua estrutura interna e comportamento, possvel
criar essas classes em J ava.
Na UML, a representao para uma classe no diagrama de classes tipicamente
expressa na forma grfica, como mostrado na Figura a seguir.

Como se observa na figura, a especificao de uma classe composta por trs
regies: o nome da classe, o conjunto de atributos da classe e o conjunto de mtodos da
classe. O nome da classe um identificador para a classe, que permite referenci-la
posteriormente, por exemplo, no momento da criao de um objeto.
O conjunto de atributos descreve as propriedades da classe. Cada atributo
identificado por um nome e tem um tipo associado. Em uma linguagem de programao
orientada a objetos pura, o tipo o nome de uma classe. Na prtica, a maior parte das
linguagens de programao orientada a objetos oferecem um grupo de tipos primitivos,
como inteiro, real e carter, que podem ser usados na descrio de atributos. O atributo

pode ainda ter um valor default opcional, que especifica um valor inicial para o
atributo.
Os mtodos definem as funcionalidades da classe, ou seja, o que ser possvel fazer
com objetos dessa classe. Cada mtodo especificado por uma assinatura, composta por
um identificador para o mtodo (o nome do mtodo), o tipo para o valor de retorno e
sua lista de argumentos, sendo cada argumento identificado por seu tipo e nome.
Atravs do mecanismo de sobrecarga (overloading), dois mtodos de uma classe
podem ter o mesmo nome, desde que suas assinaturas sejam diferentes. Tal situao no
gera conflito, pois o compilador capaz de detectar qual mtodo deve ser escolhido a
partir da anlise dos tipos dos argumentos do mtodo. Nesse caso, diz-se que ocorre a
ligao prematura (early binding) para o mtodo correto.
O modificador de visibilidade pode estar presente tanto para atributos como para
mtodos. Em princpio, trs categorias de visibilidade podem ser definidas:
+: Pblico: denotado em UML pelo smbolo (+), nesse caso, o atributo ou
mtodo de um objeto dessa classe pode ser acessado por qualquer outro objeto
(visibilidade externa total);
-: Privativo: denotado em UML pelo smbolo (-), nesse caso, o atributo ou
mtodo de um objeto dessa classe no pode ser acessado por nenhum outro
objeto (nenhuma visibilidade externa);
#: Protegido: denotado em UML pelo smbolo (#), nesse caso, o atributo ou
mtodo de um objeto dessa classe poder ser acessado apenas por objetos de
classes que sejam derivadas dessa atravs do mecanismo de herana.
1.1.2 Objetos
Objetos so instncias de classes. atravs deles que (praticamente) todo o
processamento ocorre em sistemas implementados com linguagens de programao
orientadas a objetos. O uso racional de objetos, obedecendo aos princpios associados
sua definio conforme estabelecido no paradigma de desenvolvimento orientado a
objetos, chave para o desenvolvimento de sistemas complexos e eficientes.
Um objeto um elemento que representa, no domnio da soluo, alguma entidade
(abstrata ou concreta) do domnio de interesse do problema sobre anlise. Objetos
similares so agrupados em classes.
No paradigma de orientao a objetos, tudo pode ser potencialmente representado
como um objeto. Sob o ponto de vista da programao orientada a objetos, um objeto
no muito diferente de uma varivel normal. Por exemplo, quando se define uma
varivel do tipo int em uma linguagem de programao como C ou J ava, essa varivel
tem:
Um espao em memria para registrar o seu estado (valor);

Um conjunto de operaes que podem ser aplicadas a ela, atravs dos operadores
definidos na linguagem que podem ser aplicados a valores inteiros.
Da mesma forma, quando se cria um objeto, esse objeto adquire um espao em
memria para armazenar seu estado (os valores de seu conjunto de atributos, definidos
pela classe) e um conjunto de operaes que podem ser aplicadas ao objeto (o conjunto
de mtodos definidos pela classe). Um programa orientado a objetos composto por um
conjunto de objetos que interagem atravs de trocas de mensagens. Na prtica, essa
troca de mensagem traduz-se na aplicao de mtodos a objetos.
As tcnicas de programao orientada a objetos recomendam que a estrutura de um
objeto e a implementao de seus mtodos devem ser to privativos como possvel.
Normalmente, os atributos de um objeto no devem ser visveis externamente. Da
mesma forma, de um mtodo deve ser suficiente conhecer apenas sua especificao,
sem necessidade de saber detalhes de como a funcionalidade que ele executa
implementada.
Encapsulao o princpio de projeto pelo qual cada componente de um programa
deve agregar toda a informao relevante para sua manipulao como uma unidade
(uma cpsula). Aliado ao conceito de ocultamento de informao um poderoso
mecanismo da programao orientada a objetos. Ocultamento da informao o
princpio pelo qual cada componente deve manter oculta sob sua guarda uma deciso de
projeto nica. Para a utilizao desse componente, apenas o mnimo necessrio para sua
operao deve ser revelado (tornado pblico).
Na orientao a objetos, o uso da encapsulao e ocultamento da informao
recomenda que a representao do estado de um objeto deve ser mantida oculta. Cada
objeto deve ser manipulado exclusivamente atravs dos mtodos pblicos do objeto, dos
quais apenas a assinatura deve ser revelada.
O conjunto de assinaturas dos mtodos pblicos da classe constitui sua interface
operacional. Dessa forma, detalhes internos sobre a operao do objeto no so
conhecidos, permitindo que o usurio do objeto trabalhe em um nvel mais alto de
abstrao, sem preocupao com os detalhes internos da classe. Essa facilidade permite
simplificar a construo de programas com funcionalidades complexas, tais como
interfaces grficas ou aplicaes distribudas.
1.1.3 Herana
O conceito de encapsular estrutura e comportamento em um tipo no exclusivo da
orientao a objetos; particularmente, a programao por tipos abstratos de dados segue
esse mesmo conceito. O que torna a orientao a objetos nica o conceito de herana.
Herana um mecanismo que permite que caractersticas comuns a diversas
classes sejam fatoradas em uma classe base, ou superclasse. A partir de uma classe
base, outras classes podem ser especificadas. Cada classe derivada ou subclasse

apresenta as caractersticas (estrutura e mtodos) da classe base e acrescenta a elas o que
for definido de particularidade para ela.
H vrias formas de relacionamentos em herana:
Extenso: a subclasse estende a superclasse, acrescentando novos membros
(atributos e/ou mtodos). A superclasse permanece inalterada, motivo pelo qual
este tipo de relacionamento normalmente referenciado como herana estrita.
Especificao: a superclasse especifica o que uma subclasse deve oferecer, mas
no implementa nenhuma funcionalidade. Diz-se que apenas a interface
(conjunto de especificao dos mtodos pblicos) da superclasse herdada pela
subclasse.
Combinao de extenso e especificao: a subclasse herda a interface e uma
implementao padro de (pelo menos alguns de) mtodos da superclasse. A
subclasse pode ento redefinir mtodos para especializar o comportamento em
relao ao que oferecido pela superclasse, ou ter que oferecer alguma
implementao para mtodos que a superclasse tenha declarado, mas no
implementado. Normalmente, este tipo de relacionamento denominado herana
polimrfica.
A ltima forma , sem dvida, a que mais ocorre na programao orientada a
objetos. Algumas modelagens introduzem uma forma de herana conhecida como
contrao. Contrao uma variante de herana onde a subclasse elimina mtodos da
superclasse com o objetivo de criar uma classe mais simples. A eliminao pode
ocorrer pela redefinio de mtodos com corpo vazio. O problema com este mecanismo
que ele viola o princpio da substituio, segundo o qual uma subclasse deve poder
ser utilizada em todos os pontos onde a superclasse poderia ser utilizada. Se a contrao
parece ser uma soluo adequada em uma hierarquia de classes, provavelmente a
hierarquia deve ser reanalisada para deteco de inconsistncias. De modo geral, o
mecanismo de contrao deve ser evitado.
1.1.4 Polimorfismo
Polimorfismo o princpio pelo qual duas ou mais classes derivadas de uma
mesma superclasse podem invocar mtodos que tm a mesma identificao
(assinatura), mas comportamentos distintos, especializados para cada classe derivada,
usando para tanto uma referncia a um objeto do tipo da superclasse. Esse mecanismo
fundamental na programao orientada a objetos, permitindo definir funcionalidades
que operem genericamente com objetos, abstraindo-se de seus detalhes particulares
quando esses no forem necessrios.
Para que o polimorfismo possa ser utilizado, necessrio que os mtodos que
estejam sendo definidos nas classes derivadas tenham exatamente a mesma assinatura
do mtodo definido na superclasse; nesse caso, est sendo utilizado o mecanismo de
redefinio de mtodos (overriding). Esse mecanismo de redefinio muito diferente
do mecanismo de sobrecarga de mtodos, onde as listas de argumentos so diferentes.

No caso do polimorfismo, o compilador no tem como decidir qual o mtodo que
ser utilizado se o mtodo foi redefinido em outras classes, afinal, pelo princpio da
substituio um objeto de uma classe derivada pode estar sendo referenciado como
sendo um objeto da superclasse. Se esse for o caso, o mtodo que deve ser selecionado
o da classe derivada e no o da superclasse.
Dessa forma, a deciso sobre qual dos mtodos mtodo que deve ser selecionado,
de acordo com o tipo do objeto, pode ser tomada apenas em tempo de execuo, atravs
do mecanismo de ligao tardia. O mecanismo de ligao tardia tambm conhecido
pelos termos em ingls late binding, dynamic binding ou ainda runtime binding.
1.2 A UML A Linguagem de Modelagem Unificada (Unified Modeling Language)
A UML uma linguagem visual utilizada para modelar softwares baseados no
paradigma de orientao a objeto. uma linguagem de modelagem de propsito geral
que pode ser aplicada a todos os domnios de aplicao. Essa linguagem tornou-se, nos
ltimos anos, a linguagem padro de modelagem adotada internacionalmente pela
indstria de engenharia do software (GUEDES, 2011).
A UML uma linguagem visual (isto , uma notao de desenho com semntica)
utilizada para criar modelos de programas, ou quais podem ser entendidos como uma
representao diagramtica dos programas. Nela podemos ver os relacionamentos
entre os objetos no cdigo (SHALLOWAY e TROTT, 2004).
A UML possui diferentes tipos de diagramas, alguns para anlise, outros para
projetos e outros ainda para implementao. Cada diagrama, dependendo de seu
propsito, mostra os relacionamentos entre diferentes conjuntos de entidades.
1.2.1 Classes
Uma classe a descrio de um tipo de objeto. Todos os objetos so instncias de
classes, onde a classe descreve as propriedades e comportamentos daquele objeto.
Objetos s podem ser instanciados de classes. Usam-se classes para classificar os
objetos que identificamos no mundo real. Uma classe pode ser a descrio de um objeto
em qualquer tipo de sistema.

Em UML as classes so representadas por um retngulo dividido em trs
compartimentos: o compartimento de nome, que conter apenas o nome da classe
modelada, o de atributos, que possuir a relao de atributos que a classe possui em sua

estrutura interna, e o compartimento de operaes, que sero os mtodos de
manipulao dedados e de comunicao de uma classe com outras do sistema. A sintaxe
usada em cada um destes compartimentos independente de qualquer linguagem de
programao, embora possam ser usadas outras sintaxes.
Exemplo: classe turma
Atributos: sala, horrio;
Operaes: obter local, adicionar estudante, obter horrio;
1.2.2 Objetos
Um objeto um elemento que podemos manipular e acompanhar seu
comportamento, criar, destruir, etc. Um objeto existe no mundo real. Pode ser uma parte
de qualquer tipo de sistema, por exemplo, uma mquina, uma organizao, ou negcio.
Existem objetos que no encontramos no mundo real, mas que podem ser vistos de
derivaes de estudos da estrutura e comportamento de outros objetos do mundo real.
Um objeto num sistema possui trs propriedades: estado, comportamento e
identidade:
Estado: definido pelo conjunto de propriedades do objeto (os atributos) e de
suas relaes com os outros objetos. algo que muda com o tempo, por
exemplo, um objeto turma pode estar no estado aberto ou fechado. Inicia no
estado aberto e fecha quando 10 alunos fazem inscrio.
Comportamento: como um objeto responde s solicitaes dos outros e tudo
mais o que um objeto capaz de fazer. implementado por um conjunto de
operaes. Ex. objeto turma pode ter operaes acrescentar aluno ou suprimir
aluno.
Identidade: significa que cada objeto nico no sistema. Por exemplo, o objeto
turma Tecno-OO manh diferente do objeto Tecno-OO tarde.


Em UML um objeto mostrado como uma classe s que seu nome (do objeto)
sublinhado, e o nome do objeto pode ser mostrado opcionalmente precedido do nome da
classe.
1.2.3 Estados
Todos os objetos possuem um estado que significa o resultado de atividades
executadas pelo objeto, e normalmente determinada pelos valores de seus atributos e
ligaes com outros objetos.
Um objeto muda de estado quando acontece algo, o fato de acontecer alguma coisa
como objeto chamado de evento. Atravs da anlise da mudana de estados dos tipos
de objetos de um sistema, podemos prever todos os possveis comportamentos dos
objetos de acordo com os eventos que o mesmo possa sofrer.

Um estado, em sua notao, pode conter trs compartimentos. O primeiro mostra o
nome do estado. O segundo opcional e mostra a varivel do estado, onde os atributos
do objeto em questo podem ser listados e atualizados. Os atributos so aqueles
mostrados na representao da classe, e em algumas vezes, podem ser mostradas
tambm as variveis temporrias, que so muito teis em diagramas de estado, j que
atravs da observncia de seus valores podemos perceber a sua influncia na mudana
de estados de um objeto.
O terceiro compartimento opcional e chamado de compartimento de atividade,
onde eventos e aes podem ser listados. Trs eventos padres podem ser mostrados no
compartimento de atividades de um estado: entrar, sair e fazer. O evento entrar pode ser
usado para definir atividades no momento em que o objeto entra naquele estado.
O evento sair define atividades que o objeto executa antes de passar para o prximo
estado e o evento fazer define as atividades do objeto enquanto se encontra naquele
estado.
1.2.4 Pacotes
Pacote um mecanismo de agrupamento, onde todos os modelos de elementos
podem ser agrupados. Em UML, um pacote definido como: Um mecanismo de
propsito geral para organizar elementos semanticamente relacionados em grupos.
Todos os modelos de elementos que so ligados ou referenciados por um pacote so
chamados de Contedo do pacote.

Um pacote possui vrios modelos de elementos, e isto significa que estes no
podem ser includos em outros pacotes.

Pacotes podem importar modelos de elementos de outros pacotes. Quando um
modelo de elemento importado, refere-se apenas a o pacote que possui o elemento. Na
grande maioria dos casos, os pacotes possuem relacionamentos com outros pacotes.
Embora estes no possuam semnticas definidas para suas instncias. Os
relacionamentos permitidos entre pacotes so de dependncia, refinamento e
generalizao (herana).
O pacote tem uma grande similaridade com a agregao (relacionamento que ser
tratado mais na frente). O fato de um pacote ser composto de modelos de elementos cria
uma agregao de composio. Se este for destrudo, todo o seu contedo tambm ser.
1.2.5 Relacionamentos
Os relacionamentos ligam as classes/objetos entre si criando relaes lgicas entre
estas entidades. Os relacionamentos podem ser dos seguintes tipos:
Associao: uma conexo entre classes, e tambm significa que uma
conexo entre objetos daquelas classes. Em UML, uma associao definida
comum relacionamento que descreve uma srie de ligaes, onde a ligao
definida como a semntica entre as duplas de objetos ligados.
Generalizao: um relacionamento de um elemento mais geral e outro mais
especfico. O elemento mais especfico pode conter apenas informaes
adicionais. Uma instncia (um objeto uma instncia de uma classe) do
elemento mais especfico pode ser usada onde o elemento mais geral seja
permitido.
Dependncia e Refinamentos: Dependncia um relacionamento entre
elementos, um independente e outro dependente. Uma dependncia
representada graficamente por uma seta aberta, com linha tracejada.


A seta que representa a relao de dependncia sai do item dependente e aponta
para o item independente.

Uma modificao um elemento independente afetar diretamente elementos
dependentes do anterior. Refinamento um relacionamento entre duas descries
de uma mesma entidade, mas em nveis diferentes de abstrao.
1.2.5.1 Associaes
Uma associao representa que duas classes possuem uma ligao (link) entre elas,
significando, por exemplo, que elas conhecem uma a outra, esto conectadas com,
para cada X existe um Y e assim por diante. Classes e associaes so muito
poderosas quando modeladas em sistemas complexos.
Associao Normal: O tipo mais comum de associao apenas uma conexo
entre classes. representada por uma linha slida entre duas classes. A associao
possui um nome (junto linha que representa a associao), normalmente um verbo,
mas substantivos tambm so permitidos.

No exemplo grfico acima vemos um relacionamento por associao entre as
classes Funcionrio e Departamento.
Pode-se tambm colocar uma seta no final da associao indicando que esta s
pode ser usada para o lado onde a seta aponta. Mas associaes tambm podem possuir
dois nomes, significando um nome para cada sentido da associao.
Para expressar a multiplicidade entre os relacionamentos, um intervalo indica
quantos objetos esto relacionados no link. O intervalo pode ser de zero para um (0..1),
zero para vrios (0..* ou apenas*), um para vrios (1..*), dois (2), cinco para 11 (5..11)
e assim por diante. tambm possvel expressar uma srie de nmeros como (1, 4,
6..12). Se no for descrito nenhuma multiplicidade, ento considerado o padro de um
para um (1..1 ou apenas 1).
Associao Recursiva: possvel conectar uma classe a ela mesma atravs de uma
associao e que ainda representa semanticamente a conexo entre dois objetos, mas os

objetos conectados so da mesma classe. Uma associao deste tipo chamada de
associao recursiva.

Associao Qualificada: Associaes qualificadas so usadas com associaes de
um para vrios (1..*) ou vrios para vrios (*). O qualificador (identificador da
associao qualificada) especifica como um determinado objeto no final da associao
n identificado, e pode ser visto como um tipo de chave para separar todos os objetos
na associao. O identificador desenhado como uma pequena caixa no final da
associao junto classe de onde a navegao deve ser feita.

Associao Exclusiva: Em alguns modelos nem todas as combinaes so vlidas,
e isto pode causar problemas que devem ser tratados. Uma associao exclusiva uma
restrio em duas ou mais associaes. Ela especifica que objetos de uma classe podem
participar de no mximo uma das associaes em um dado momento. Uma associao
exclusiva representada por uma linha tracejada entre as associaes que so partes
da associao exclusiva, com a especificao {ou} sobre a linha tracejada.

No diagrama acima um contrato no pode se referir a uma pessoa e a uma empresa ao
mesmo tempo, significando que o relacionamento exclusivo a somente uma das duas
classes.

Associao Ordenada: As associaes entre objetos podem ter uma ordem
implcita. O padro para uma associao desordenada (ou sem nenhuma ordem
especfica). Mas uma ordem pode ser especificada atravs da associao ordenada. Este
tipo de associao pode ser muito til em casos como este: janelas de um sistema tm
que ser ordenadas na tela (uma est no topo, uma est no fundo e assim por diante). A
associao ordenada pode ser escrita apenas colocando {ordenada} junto linha de
associao entre as duas classes.
Associao de Classe: Uma classe pode ser associada outra associao. Este tipo
de associao no conectada a nenhuma das extremidades da associao j existente,
mas na prpria linha da associao. Esta associao serve para se adicionar informaes
extras a associao j existente.
A associao da classe Fila com a associao das classes Cliente e Processo pode
ser estendida com operaes de adicionar processos na fila, para ler e remover da fila e
de ler o seu tamanho. Se operaes ou atributos so adicionados associao, ela deve
ser mostrada como uma classe.

Associao Ternria: Mais de duas classes podem ser associadas entre si, a
associao ternria associa trs classes. Ela mostrada como um losango grande
(diamante) e ainda suporta uma associao de classe ligada a ela, se traaria, ento, uma
linha tracejada a partir do losango para a classe onde seria feita a associao ternria.

No exemplo acima a associao ternria especifica que um cliente poder possuir
1oumais contratos e cada contrato ser composto de1 ou vrias regras contratuais.

Agregao: A agregao um caso particular da associao. A agregao indica
que uma das classes do relacionamento uma parte, ou est contida em outra classe. As
palavras chaves usadas para identificar uma agregao so: consiste em, contm,
parte de. A agregao tambm conhecida como relacionamento tem-um, ou seja,
dizemos que um objeto gerado da classe todo tem um objeto gerado da classe
parte.

Existem tipos especiais de agregao que so as agregaes compartilhadas e as
compostas.
Agregao Compartilhada: dita compartilhada quando uma das classes
uma parte, ou est contida na outra, mas esta parte pode estar contida nas outras
vrias vezes e num mesmo momento.

No exemplo acima uma pessoa pode ser membro de um time ou vrios times em
determinado momento.
Agregao de Composio: uma agregao onde uma classe que est
contida na outra vive e constitui a outra. Se o objeto da classe que contm for
destrudo, as classes da agregao de composio sero destrudas juntamente j
que as mesmas fazem parte da outra.

1.2.5.2 Generalizaes
A generalizao um relacionamento hierrquico entre classes, isto , a
generalizao um relacionamento entre um elemento geral e outro mais especfico. O
elemento mais especfico possui todas as caractersticas do elemento geral e contm
ainda mais particularidades. Um objeto mais especfico pode ser usado como uma

instncia do elemento mais geral. A generalizao, tambm chamada de herana,
permite a criao de elementos especializados em outros.
A classe de maior nvel hierrquico conhecida como superclasse, enquanto a
outra classe da relao conhecida como subclasse. Graficamente uma generalizao
representada por uma linha contnua com uma seta em branco apontando sempre a
superclasse.

Existem alguns tipos de generalizaes que variam em sua utilizao a partir da
situao. So elas: generalizao normal e restrita. As generalizaes restritas se
dividem em generalizao de sobreposio, disjuntiva, completa e incompleta.
Generalizao Normal: Na generalizao normal a classe mais especfica,
chamada de subclasse, herda tudo da classe mais geral, chamada de superclasse. Os
atributos, operaes e todas as associaes so herdados.

public class ContaCorrente {}
public class Poupana extends ContaCorrente {}

Uma classe pode ser tanto uma subclasse quanto uma superclasse, se ela estiver
numa hierarquia de classes que um grfico onde as classes esto ligadas atravs de
generalizaes.

A generalizao normal representada por uma linha entre as duas classes que
fazem o relacionamento, sendo que se coloca uma seta no lado da linha onde se
encontra a superclasse indicando a generalizao.
Generalizao Restrita: Uma restrio aplicada a uma generalizao especifica
informaes mais precisas sobre como a generalizao deve ser usada e estendida no
futuro. As restries a seguir definem mais generalizaes restritas com mais de uma
subclasse:
Generalizaes de Sobreposio e Disjuntiva: Generalizao de sobreposio
significa que quando subclasses herdam de uma superclasse por sobreposio,

novas subclasses destas podem herdar de mais de uma subclasse. A
generalizao disjuntiva exatamente o contrrio da sobreposio e a
generalizao utilizada como padro.

Generalizaes Completas e Incompletas: Uma restrio simbolizando que
uma generalizao completa significa que todas as subclasses j foram
especificadas, e no existe mais possibilidade de outra generalizao a partir
daquele ponto. A generalizao incompleta exatamente o contrrio da
completa e assumida como padro da linguagem.

1.2.5.3 Dependncias e Refinamentos
Alm das associaes e generalizaes, existem a inda dois tipos de
relacionamentos em UML. O relacionamento de dependncia uma conexo semntica
entre dois modelos de elementos, um independente e outro dependente. Uma mudana
no elemento independente ir afetar o modelo dependente.
Como no caso anterior com generalizaes, os modelos de elementos podem ser
uma classe, um pacote, um caso de uso e assim por diante. Quando uma classe recebe
um objeto de outra classe como parmetro, uma classe acessa o objeto global da outra.
Nesse caso existe uma dependncia entre estas duas classes, apesar de no ser
explcita. Uma relao de dependncia simbolizada por uma linha tracejada com uma
seta no final de um dos lados do relacionamento.

E sobre essa linha o tipo de dependncia que existe entre as duas classes. As classes
Amigas provenientes do C++so um exemplo de um relacionamento de dependncia

Os refinamentos so um tipo de relacionamento entre duas descries de uma
mesma coisa, mas em nveis de abstrao diferentes e podem ser usados para modelar
diferentes implementaes de uma mesma coisa (uma implementao simples e outra
mais complexa, mas tambm mais eficiente).

Os refinamentos so simbolizados por uma linha tracejada comum tringulo no
final de um dos lados do relacionamento e so usados em modelos de coordenao. Em
grandes projetos, todos os modelos que so feitos devem ser coordenados.
Coordenao de modelos pode ser usada para mostrar modelos em diferentes nveis
de abstrao que se relacionam e mostram tambm como modelos em diferentes fases
de desenvolvimento se relacionam.
1.2.6 Mecanismos Gerais
AUML utiliza alguns mecanismos em seus diagramas para tratar informaes
adicionais.
Ornamentos: Ornamentos grficos so anexados aos modelos de elementos em
diagramas e adicionam semnticas ao elemento. Um exemplo de um ornamento o da
tcnica de separar um tipo de uma instncia. Quando um elemento representa um tipo,
seu nome mostrado em negrito. Quando o mesmo elemento representa a instncia de
um tipo, seu nome escrito sublinhado e pode significar tanto o nome da instncia
quanto o nome do tipo.
Outros ornamentos so os de especificao de multiplicidade de relacionamentos,
onde a multiplicidade um nmero ou um intervalo que indica quantas instncias de um
tipo conectado pode estar envolvido na relao.
Notas: Nem tudo pode ser definido em uma linguagem de modelagem, sem
importar o quanto extensa ela seja. Para permitir adicionar informaes a um modelo
no poderia ser representado de outra forma, UML prov a capacidade de adicionar
Notas.
Uma Nota pode ser colocada em qualquer lugar em um diagrama, e pode conter
qualquer tipo de informao.


1.3 PADRES DE PROJ ETOS DE SOFTWARE
Um dos principais problemas do desenvolvimento de software orientado a objetos
projetar software reutilizvel. Na maioria das vezes, e isso aconteceu muito na dcada
passada, e ainda acontece hoje, que h uma tendncia, mesmo em projetos com
linguagens orientadas a objetos, em comear uma soluo do zero ou usar as velhas
tcnicas estruturadas utilizadas durante muito tempo, assim mais fcil.
No entanto, o que deve ser observado, que j existem tcnicas orientadas a objetos
que solucionam problemas recorrentes de software, no necessrio comear do zero
ou partir para tcnicas usadas em um passado distante.
Essas tcnicas so denominadas padres de projeto (Design Patterns), assim, ao
longo do processo evolutivo do desenvolvimento orientado a objetos foram surgindo
solues brilhantes para problemas recorrentes de software, essas solues foram
documentadas e reutilizadas para cada propsito, proporcionando rapidez no
desenvolvimento de software, reutilizao de modelo de classes e cdigo e
padronizao das solues.
Tudo comeou na dcada de 1970 quando Christopher Alexander, um arquiteto
austraco, lanou as ideias iniciais sobre o uso de padres para o setor das construes.
Em 1987, surgiram os primeiros padres para a rea de Cincia da Computao,
propostos por Kent Beck e Ward Cunningham, usando a linguagem Smalltalk.
O modelo MVC (Model-View-Controller) foi um dos pioneiros, usado para atender
usurios Smaltalk-80, esse modelo previa o Modelo (a aplicao), a Viso (a tela) e o
Controlador (reao da interface dos usurios s entradas de dados do mesmo). Nesse
modelo, eram apresentados os fundamentos dos padres de projeto e como esses
poderiam evoluir para outras situaes recorrentes de produo de software.
Na dcada de 1990 surgiram os padres GoF (Gang of Four gangue dos quatro),
dos autores Erich Gamma, Richard Helm, Ralph J ohnson, J ohn Vlissides. Foi lanado o
livro: Design Patterns: Elements of Reusable Object-Oriented Software. 1 ed. Estados
Unidos: Addison-Wesley, 1995. Mais tarde surgem outros padres como o padro
GRASP (General Responsibility Assignment Software Patterns), mas de um modo
geral, os 23 padres de projetos GoF definidos pela gangue do quatro, so os mais
utilizados no mercado e so esses padres o objetivo do estudo.

1.4 O QUE UM PADRO DE PROJETO?
O Design Patterns so padres de classes e de relacionamentos entre as mesmas
que aparecem de forma frequente em projetos de software. Tais padres so
categorizados para atender a solues especficas. Sua utilizao uma atividade que
simplifica a reutilizao de software. Os padres aparecem em situaes especiais
dentro de um sistema como descries de objetos e classes comunicantes que so
customizadas um contexto particular. Este descreve uma soluo comprovada para um
problema, so mais abstratos, menores e menos especficos que frameworks que por sua
vez um conjunto de classes que pode ser utilizado para um tipo especfico de projeto
de software (anlise de domnio, biblioteca de reuso).
Os padres so dispositivos que permitem que os programas compartilhem
conhecimento sobre o seu desenho. Quando programamos, encontramos muitos
problemas que ocorrem, ocorreram e iro ocorrer novamente. A questo que nos
perguntamos agora como ns vamos solucionar este problema desta vez? Documentar
um padro uma maneira de poder reusar e possivelmente compartilhar informao que
aprendeu sobre a melhor maneira de se resolver um problema de desenho de software.
O catlogo de padres do GoF (Gang Of Four), contm 23 padres e est, basicamente,
dividido em trs sees: Criao (Creational), Estrutural (Structural), Comportamental
(Behavioral).
Dentre as principais propriedades dos padres de projetos podemos citar:
1. Capturam o conhecimento e a experincia de especialistas em projeto de
software.
2. Especificam abstraes que esto acima do nvel de classes ou objetos isolados
ou de componentes.
3. Definem um vocabulrio comum para a discusso de problemas e solues de
projeto.
4. Facilitam a documentao e manuteno da arquitetura do software.
5. Auxiliam o projeto de uma arquitetura com determinadas propriedades.
6. Auxiliam o projeto de arquiteturas mais complexas.
Dentre os principais benefcios para a utilizao dos padres de projeto esto:
1. Fornecem solues que j foram testadas e aprovadas.
2. Tornam o sistema mais fcil de entender e manter.
3. Facilitam o desenvolvimento de mdulos coesos.
4. A comunicao entre os participantes do projeto fica mais eficiente
Quando e como utilizar padres de projetos. A primeira coisa que devemos ter
bom senso. Teste e implemente sua soluo e veja se ela funciona. A seguir verifique se
ela pode ser otimizada, se for o caso utilize o padro de projeto que se ajuste ao seu caso
para melhorar as deficincias verificadas no seu projeto. Naturalmente isto ser mais
fcil se tiver uma viso global do seu projeto e seu funcionamento.

Um padro de projeto pode ser definido como:
uma tcnica usada para identificar, abstrair, documentar e padronizar os
diversos aspectos recorrentes do projeto de software orientado a objetos, de modo a
torn-los reutilizveis em outros projetos (FREEMAN e FREEMAN, 2007).
os padres de projeto fornecem um vocabulrio compartilhado com outros
desenvolvedores. Quando voc tem um vocabulrio, pode se comunicar mais facilmente
com outros desenvolvedores e inspirar aqueles que no conhecem os padres a
comear a aprend-los. Isso tambm eleva o seu raciocnio sobre as arquiteturas,
permitindo que voc pense no nvel do padro e no no nvel de cdigo (FREEMAN e
FREEMAN, 2007).
Cada padro descreve um problema no nosso ambiente e o cerne da sua soluo,
de tal forma que voc possa usar essa soluo mais de um milho de vezes, sem nunca
faz-lo da mesma maneira (GAMMA, HELM, et al., 2000).
Em geral, um padro tem quatro elementos essenciais:
1. Nome do Padro: Uma referncia usada para descrever um problema recorrente
de projeto, suas solues e consequncias em uma ou duas palavras.
2. Problema: Usado para descrever em que situao o padro deve ser usado.
Explica o problema e o contexto.
3. Soluo: Usado para descrever os elementos que compem o padro:
relacionamentos, responsabilidades e colaboraes.
4. Consequncias: Vantagens e desvantagens da aplicao do padro.
1.5 COMO DESCREVER UM PADRO DE PROJ ETO
Existem diversas formas de descrever um padro de projeto. No entanto,
independente do formato, alguns componentes devem ser facilmente reconhecidos
quando da leitura de um padro de projeto. A forma aqui descrita conhecida como
forma cannica.
Nome e Classificao. Deve expressar a essncia do padro. Um bom nome
vital, pois vai se tornar parte do vocabulrio do projeto.
Inteno e Objetivo. uma curta declarao que responde s seguintes
questes: o que faz o padro de projeto? Quais os seus princpios e sua inteno?
Que tpico ou problema particular de projeto ele trata?
Propsito. O que faz um padro de projeto? Qual o problema que se prope a
atacar? Quais os objetivos que deseja alcanar?
Motivao. Descreve o cenrio no qual se aplica todas as foras que esto
presentes, as classes e os objetos relacionados.
Aplicabilidade. Quais so as situaes na qual o padro de projeto pode ser
aplicado? Como reconhecer estas situaes?
Estrutura. Um diagrama da UML que represente o padro.

Participantes. Descreve as classes e/ou objetos que participam no padro de
projeto e suas responsabilidades.
Colaboraes. Descreve como os participantes colaboram entre si para realizar
suas responsabilidades. Assim, a soluo descreve no somente a estruturas
estticas, mas tambm a dinmica comportamental dos objetos e classes.
Consequncias. Quais os resultados obtidos com a aplicao do padro de
projeto? O que foi resolvido, o que no foi resolvido e que padro de projeto
pode ser aplicado neste momento?
Implementao. Quais so as dicas, os macetes e as tcnicas que devem estar
claras quando da implementao do padro. H questes relativas a uma
linguagem especfica.
Exemplos de cdigo. Exemplos de sistemas reais, onde o padro de projeto foi
aplicado e que transformaes ocorreram dentro de cada contexto.
Padres relacionados. Qual padro de projeto tem relao com este padro de
projeto? Quais so as diferenas importantes? Com que outros padres, este
deve ser usado.
1.6 PRINCIPAIS PADRES DE PROJ ETO
1.6.1 Finalidade dos 23 padres:
1. Adapter. Converter a interface de uma classe em outra interface esperada pelos
clientes.
2. Faade. Oferecer uma interface nica de nvel mais elevado para um conjunto
de interfaces de um subsistema.
3. Composite. Permitir o tratamento de objetos individuais e composies desses
objetos de maneira uniforme.
4. Bridge. Desacoplar uma abstrao de sua implementao para que os dois
possam variar independentemente.
5. Singleton. Garantir que uma classe s tenha uma nica instncia, e prover um
ponto de acesso global a ela.
6. Observer. Definir uma dependncia um-para-muitos entre objetos para que
quando um objeto mudar de estado, os seus dependentes sejam notificados e
atualizados automaticamente.
7. Mediator. Definir um objeto que encapsula a forma como um conjunto de
objetos interage.
8. Proxy. Prover um substituto ou ponto atravs do qual um objeto possa controlar
o acesso a outro.
9. Chain of Responsibility. Compor objetos em cascata para, atravs dela, delegar
uma requisio at que um objeto a sirva.
10. Flyweight. Usar compartilhamento para suportar eficientemente grandes
quantidades de objetos complexos.
11. Builder. Separar a construo de objeto complexo da representao para criar
representaes diferentes com mesmo processo.

12. Factory Method. Definir uma interface para criar um objeto, mas deixar que
subclasses decidam que classe instanciar.
13. Abstract Factory. Prover interface para criar famlias de objetos relacionados
ou dependentes sem especificar suas classes concretas.
14. Prototype. Especificar tipos a criar usando uma instncia como prottipo e
criar novos objetos ao copiar este prottipo.
15. Memento. Externalizar o estado interno de um objeto para que o objeto possa
ter esse estado restaurado posteriormente.
16. Template Method. Definir o esqueleto de um algoritmo dentro de uma
operao, deixando alguns passos a serem preenchidos pelas subclasses.
17. State. Permitir a um objeto alterar o seu comportamento quanto o seu estado
interno mudar.
18. Strategy. Definir uma famlia de algoritmos, encapsular cada um, e faz-los
intercambiveis.
19. Command. Encapsular requisio como objeto, para clientes parametrizarem
diferentes requisies, filas, e suportar operaes reversveis.
20. Interpreter. Dada uma linguagem, definir uma representao para sua
gramtica junto com um interpretador.
21. Decorator. Anexar responsabilidades adicionais a um objeto dinamicamente.
22. Iterator. Prover uma maneira de acessar elementos de um objeto agregado
sequencialmente sem expor sua representao interna.
23. Visitor. Representar uma operao a ser realizada sobre os elementos de uma
estrutura de objetos.
Os 23 padres de projeto se dividem em categorias segundo (GAMMA, HELM, et
al., 2000), e so elas: Criao de classes de objetos, alterao da Estrutura de um
programa, e controle de seu Comportamento. A figura 1 mostra os padres GoF,
divididos em suas respectivas categorias.
O primeiro critrio, chamado de finalidade, reflete o que um padro faz. Os
padres podem ter finalidade de criao, estrutural ou comportamental. Os padres de
criao se preocupam com o processo de criao de objetos. Os padres de criao se
preocupam com o processo de criao de objetos. Os padres estruturais lidam com a
composio de classes ou de objetos. Os padres comportamentais caracterizam as
maneiras pelas quais classes ou objetos interagem e distribuem responsabilidades.
O segundo critrio, chamado de escopo, especifica se o padro se aplica
principalmente a classes ou objetos. Os padres para classes lidam com os
relacionamentos entre classes e suas subclasses. Esses relacionamentos so
estabelecidos atravs do mecanismo de herana, assim eles so estticos fixados em
tempo de compilao. Os padres para objetos lidam com relacionamentos entre objetos
que podem ser mudados em tempos de execuo e so mais dinmicos. Quase todos
utilizam a herana em certa medida.


Figura 1: Classificao dos 23 padres segundo GoF
O primeiro critrio, chamado de finalidade, reflete o que um padro faz. Os
padres podem ter finalidade de criao, estrutural ou comportamental. Os padres de
criao se preocupam com o processo de criao de objetos. Os padres de criao se
preocupam com o processo de criao de objetos. Os padres estruturais lidam com a
composio de classes ou de objetos. Os padres comportamentais caracterizam as
maneiras pelas quais classes ou objetos interagem e distribuem responsabilidades.
O segundo critrio, chamado de escopo, especifica se o padro se aplica
principalmente a classes ou objetos. Os padres para classes lidam com os
relacionamentos entre classes e suas subclasses. Esses relacionamentos so
estabelecidos atravs do mecanismo de herana, assim eles so estticos fixados em
tempo de compilao. Os padres para objetos lidam com relacionamentos entre objetos
que podem ser mudados em tempos de execuo e so mais dinmicos. Quase todos
utilizam a herana em certa medida.
Os padres de criao voltados para classes deixam alguma parte da criao de
objetos para subclasses, enquanto que os padres de criao voltados para objetos
postergam esse processo para outro objeto. Os padres estruturais voltados para classes
utilizam a herana para compor classes, enquanto que os padres estruturais voltados
para objetos descrevem maneiras de montar objetos. Os padres comportamentais
voltados para classes usam a herana para descrever algoritmos e fluxo de controle,
enquanto que os voltados para objetos descrevem como um grupo de objetos coopera
para executar uma tarefa que um nico objeto no pode executar sozinho (GAMMA,
HELM, et al., 2000).
Para Metsker (METSKER, 2002) os 23 padres so classificados em cinco grupos
como mostrado na figura 2, por inteno (problema a ser solucionado):
1. Oferecer uma interface,

2. Atribuir uma responsabilidade,
3. Realizar a construo de classes ou objetos
4. Controlar formas de operao
5. Implementar uma extenso para a aplicao

Figura 2: Classificao dos padres GoF segundo Metsker

1.6.2 Como selecionar um padro?
1. Considere como os padres solucionam os problemas de projeto.
2. Analise seu problema e compare com o objetivo de cada padro.
3. Veja como os padres envolvidos se relacionam entre si.
4. Estude padres de propsito ou inteno similar (veja formas de classificao).
5. Examine causas comuns que podem forar o redesign do seu sistema.
6. Considere o que deve variar no seu design.


2. PADRES GoF
2.1 PADRES DE CRIAO
Os padres de criao abstraem o processo de instanciao. Eles ajudam a tornar
um sistema independente de como seus objetivos so criados, compostos e
representados.
Um padro de criao de classe usa a herana para variar a classe que instanciada,
enquanto que um padro de criao de objeto delegar a instanciao para outro objeto.
2.1.1 Padro Abstract Factory
Propsito:
Fornecer uma interface para criao de famlias de objetos relacionados ou
dependentes sem especificar suas classes concretas.
Motivao

Considere uma aplicao com interface grfica que implementada para
plataformas diferentes (Motif para UNIX e outros ambientes para Windows e
MacOS).
As classes implementando os elementos grficos no podem ser definidas
estaticamente no cdigo. Precisamos de uma implementao diferente para cada
ambiente. At em um mesmo ambiente, gostaramos de dar a opo ao usurio
de implementar diferentes aparncias (look-and-feels).
Podemos solucionar este problema definindo uma classe abstrata para cada
elemento grfico e utilizando diferentes implementaes para cada aparncia ou
para cada ambiente.
Ao invs de criarmos as classes concretas com o operador new, utilizamos uma
Fbrica Abstrata para criar os objetos em tempo de execuo.
O cdigo cliente no sabe qual classe concreta utilizamos.

Aplicabilidade
Use o padro Abstract Factory quando:
1. O sistema precisa ser independente de como os produtos so criados,
compostos e representados.
2. O sistema deve ser configurado com uma de mltiplas famlias de produtos.
3. Produtos de uma famlia devem ser sempre utilizados em conjunto e isto
precisa ser garantido.
4. Deseja-se disponibilizar uma biblioteca de classes de produtos, mas revelar
somente as suas interfaces, no suas implementaes.
Estrutura

Participantes
AbstractFactory:
o declara uma interface para operaes que criam objetos de produto
abstratos.
ConcreteFactory:
o implementa as operaes para criar objetos produto concretos.
AbstractProduct:
o declara uma interface para um tipo de objeto produto.
ConcreteProduct:
o define o objeto produto a ser criado pela fbrica concreta correspondente
e implementa a interface AbstractProduct.
Client:
o usa somente interfaces declaradas pelas classes AbstractFactory e
AbstractProduct.

Colaboraes
Normalmente uma nica instncia de fbrica concreta criada em runtime. Esta
fbrica cria produtos com uma implementao em particular. Para criar outros
produtos deve-se utilizar uma fbrica diferente.
As classes abstratas transferem a responsabilidade de criao dos objetos
produto para as suas subclasses.
Consequncias
Isola as classes concretas: Ele controla as classes dos objetos que a aplicao
cria. Clientes manipulam instncias somente atravs de suas interfaces abstratas.
Nomes de classes esto isolados nas fbricas concretas, eles no aparecem no
cdigo do cliente.
Torna fcil a troca de famlias de produtos: A classe da fbrica concreta sendo
utilizada aparece somente uma vez na aplicao, facilitando modificaes. A
famlia de produtos mudaria toda de uma vez.
Promove consistncia entre produtos: Garante que os objetos utilizados so
todos de uma mesma famlia, representada pela fbrica concreta sendo utilizada.
Dificulta a insero de novos tipos de produtos: A interface da fbrica abstrata
torna fixo o conjunto de produtos que podem ser criados. Suportar um novo
produto exige a extenso da interface da fbrica abstrata e a modificao de
todas as suas subclasses.
Implementao. A seguir algumas tcnicas teis para implementar o padro
Abstract factory.
Fbricas como Singletons: Geralmente precisa-se de somente uma instncia
da fbrica concreta por aplicao.
Criando os produtos: A fbrica abstrata somente define uma interface para
criao de produtos, geralmente atravs de um Factory Method para cada
produto. As fbricas concretas implementam esses Factory Methods para
instanciar os objetos. A implementao simples, mas requer uma fbrica
concreta para cada famlia de produtos, mesmo que elas sejam ligeiramente
diferentes. Se esto previstas muitas famlias, a fbrica concreta pode ser
implementada usando o padro Prototype. Teramos apenas uma fbrica
concreta, inicializada com os prottipos dos produtos desejados. Outra
variao utilizar meta-classes, se disponveis na linguagem.
Definindo fbricas extensveis: Na fbrica abstrata, os tipos de produtos
fazem parte das assinaturas dos Factory Methods. Adicionar um novo
produto requer mudar a interface da fbrica abstrata e de todas as classes
dela dependentes. Uma soluo mais flexvel porm menos segura
adicionar um parmetro ao Factory Methodindicando o tipo de produto a ser
criado. A fbrica abstrata (e concreta) teria somente um Factory Method.

Entretanto, visto que os produtos devero ter a mesma classe-base, o cliente
os enxergar de uma nica maneira, sem distinguir os tipos dos produtos.
Exemplo prtico 1. Neste exemplo, a classe abstrata WidgetFactory possui duas
especializaes: MotifWidgetFactory para widgets Motif e QtWidgetFactory para
widgets Qt. Essas especializaes so classes concretas capazes de produzir os
elementos da interface grfica. O cliente do toolkit obtm os elementos grficos de que
necessita atravs da classe (interface) WidgetFactory sem ter conhecimento das classes
concretas. Da mesma maneira, o cliente somente interage com as interfaces que
representam os elementos produzidos pela classe Abstract Factory (no exemplo, a
classe Janela e a classe Botao).

Figura 2: Estrutura exemplo prtico 1.
Implementao:
public abstract class E2WidgetFactory {
public static E2WidgetFactory obterFactory(){
if( E2Configuracao.obterInterfaceGraficaAtual() == E2Configuracao.E2MotifWidget ){
return new E2MotifWidgetFactory();
}
else{ return new E2QtWidgetFactory(); }
}
public abstract E2Botao criarBotao();
}
E2WidgetFactory.java

public class E2QtWidgetFactory extends E2WidgetFactory{
@Override
public E2Botao criarBotao() {
return new E2BotaoQt();
}
}
E2QtWidgetFactory.java
public class E2MotifWidgetFactory extends E2WidgetFactory{
@Override
public E2Botao criarBotao() {
return new E2BotaoMotif();
}
}

E2MotifWidgetFactory.java
public abstract class E2Botao {
public abstract void desenhar();
}
E2Botao .java
public class E2BotaoMotif extends E2Botao{
@Override
public void desenhar() {
System.out.println(">>Eu sou um botao Motif! <<");
}
}
E2BotaoMotif.java
public class E2BotaoQt extends E2Botao{
@Override
public void desenhar() {
System.out.println(">>Eu sou um botao Qt! <<");
}
}
E2BotaoQt.java
public class E2Configuracao {
public static final E2Configuracao E2MotifWidget =
new E2Configuracao();
public static Object obterInterfaceGraficaAtual() {
return E2MotifWidget;
}
}
E2Configuracao.java
public class E2Cliente {
public static void main(String[] args){
E2WidgetFactory factory =E2WidgetFactory.obterFactory();
E2Botao botao =factory.criarBotao();
botao.desenhar();
}
}
E2Cliente.java

Exemplo prtico 1a. Estabelecimentos comerciais normalmente oferecem aos
clientes diversas opes de pagamento. Por exemplo, clientes podem efetuar
pagamentos com dinheiro, cheque, cartes de crdito ou dbito, entre outros.
Pagamentos com cartes so realizados por meio de uma mquina de carto,
oferecida e instalada por empresas como Cielo e Redecard. Geralmente, essa mquina
capaz de lidar com cartes de diferentes bandeiras (como Visa e Mastercard).
Nosso objetivo desenvolver uma aplicao capaz de se comunicar com as
diferentes bandeiras e registrar pagamentos. No momento do pagamento, a mquina de
carto deve enviar as informaes relativas transao (como valor e senha) para a
bandeira correspondente ao carto utilizado. Alm disso, a mquina deve aguardar uma
resposta de confirmao ou recusa do pagamento.
Exerccios 1:
1. Implemente a classe Janela da figura 2.
2. Implemente uma aplicao que constri Figuras: (Use uma abstract Factory para
controlar a criao de todos os objetos)
Pontos (x, y)
Circulos (Ponto, raio)
Retangulos (Ponto, Ponto)

Triangulos (Ponto, Ponto, Ponto)
2.1.2 Padro Builder
Propsito
Separar a construo de um objeto complexo de sua representao para que o
mesmo processo de construo possa criar representaes diferentes (GAMMA, HELM,
et al., 2000). Mover a lgica de construo de uma classe para um objeto externo, a fim
de reduzir a complexidade da mesma e permitir a construo gradual de objetos-alvo a
partir dessa classe (METSKER, 2002).
Motivao
Nem sempre fcil coletar os requisitos que movem a criao de uma classe.
Mais trabalhoso , porm, instanciar objetos de uma classe que variem de acordo com
os requisitos apresentados. Por exemplo, mudar o layout de uma tela, em tempo de
execuo, quando o usurio seleciona uma opo condizente.
Mas, se fosse possvel separar da classe os seus mtodos representam o
comportamento e a construo dessa classe numa estrutura de dados a parte, seria
possvel tambm, utilizar essa estrutura para coletar as opes de um cliente e construir
objetos diferentes, conhecendo apenas os parmetros necessrios para esta construo,
provenientes dos atributos que compem a classe em questo.
Desta maneira se apresenta o padro Builder, um construtor de objetos, baseado
nos mtodos de criao e comportamento de uma classe, que pode instanciar objetos
diferentes, conhecendo apenas os atributos que compem a classe em questo.
Aplicabilidade
Builder permite que uma classe se preocupe com apenas uma parte da construo
de um objeto. til em algoritmos de construo complexos.
Use-o quando o algoritmo para criar um objeto complexo precisar ser
independente das partes que compem o objeto e da forma como o objeto
construdo.
Builder tambm suporta substituio dos construtores, permitindo que a mesma
interface seja usada para construir representaes diferentes dos mesmos dados.
Use quando o processo de construo precisar suportar representaes diferentes
do objeto que est sendo construdo.


Estrutura

Figura 3: Estrutura do Builder
Participantes
Builder
o Especifica uma interface abstrata para criao de partes de um objeto-
produto.
ConcreteBuilder
o Constri e monta partes do produto pela implementao da interface de
Builder; define e mantm a representao que cria; fornece uma interface
para recuperao do produto.
Director.
o Constri um objeto usando a interface de Builder.
Product
o Representa o objeto complexo em construo. ConcreteBuilder constri a
representao interna do produto e define o processo pelo qual ele
montado; inclui classes que definem as partes constituintes, inclusive as
interfaces para a montagem das partes no resultado final.
Consequncias
Vantagens segundo (METSKER, 2002):
Reduo da extenso e da complexidade de uma classe;
Independncia entre a representao de um objeto e a sua construo;
Criao de regras graduais de construo para um objeto;
Gerao de construes diversificadas de um tipo de objeto, ou de
construes de objetos diversificados entre si, a partir de um construtor-base;
Desvantagem:
1. Por ser bastante flexvel, este padro s apresentar desvantagem se o seu
construtor-base for mal planejado, o que poderia resultar em construes
redundantes ou com baixo aproveitamento operacional.


Exemplo prtico 2

Figura 4: UML exemplo 2
Implementao:

/** "Product" */
class Pizza {
private String dough ="";
private String sauce ="";
private String topping ="";

public void setDough(String dough) {this.dough =dough; }
public void setSauce(String sauce) {this.sauce =sauce; }
public void setTopping(String topping) {this.topping =topping; }
}

/** "Abstract Builder" */
abstract class PizzaBuilder {
protected Pizza pizza;

public Pizza getPizza() {return pizza; }
public void createNewPizzaProduct() {pizza =new Pizza(); }

public abstract void buildDough();
public abstract void buildSauce();
public abstract void buildTopping();
}

/** "ConcreteBuilder" */
class HawaiianPizzaBuilder extends PizzaBuilder {
public void buildDough() {pizza.setDough("cross"); }
public void buildSauce() {pizza.setSauce("mild"); }
public void buildTopping() {pizza.setTopping("ham+pineapple"); }
}

/** "ConcreteBuilder" */
class SpicyPizzaBuilder extends PizzaBuilder {
public void buildDough() {pizza.setDough("pan baked"); }
public void buildSauce() {pizza.setSauce("hot"); }
public void buildTopping() {pizza.setTopping("pepperoni+salami"); }
}

/** "Director" */

class Waiter {
private PizzaBuilder pizzaBuilder;

public void setPizzaBuilder(PizzaBuilder pb) {pizzaBuilder =pb; }
public Pizza getPizza() {return pizzaBuilder.getPizza(); }

public void constructPizza() {
pizzaBuilder.createNewPizzaProduct();
pizzaBuilder.buildDough();
pizzaBuilder.buildSauce();
pizzaBuilder.buildTopping();
}
}
/** A customer ordering a pizza. */
class BuilderExample {
public static void main(String[] args) {
Waiter waiter =new Waiter();
PizzaBuilder hawaiian_pizzabuilder =new HawaiianPizzaBuilder();
PizzaBuilder spicy_pizzabuilder =new SpicyPizzaBuilder();

waiter.setPizzaBuilder( hawaiian_pizzabuilder );
waiter.constructPizza();

Pizza pizza =waiter.getPizza();
System.out.println(" Pizza tipo "+pizza.getDough());
}
}

Exerccios 2:
1. Adicionar outros tipos de pizzas ao cdigo anterior.
2. Uma aplicao precisa construir objetos Pessoa, e Empresa. Para isto, precisa ler
dados de um banco para cada produto.
1. Para construir uma Pessoa preciso obter nome e identidade. Apenas se os
dois forem lidos a pessoa pode ser criada.
2. Para construir uma empresa preciso ler o nome e identidade do responsvel
e depois construir a pessoa do responsvel.
3. Mostre como poderia ser implementada uma aplicao que realizasse as tarefas
acima. Simule os dados com Strings.
2.1.3 Padro Factory Method
Propsito
Definir uma interface ou classe abstrata para a criao de um objeto, permitindo
decidir qual das implementaes ou subclasses devem ser instanciadas; deixa uma
classe deferir instanciao para subclasses (GAMMA, HELM, et al., 2000). Retornar
uma instncia dentre muitas possveis classes, dependendo dos dados providos a ele.
Motivao
til para se construir objetos individuais, para um propsito especfico, sem que
a construo requeira conhecimento das classes especficas sendo instanciadas. Uma
classe de abstrao criada, contendo um mtodo em que decide qual das opes de
classe retornar. Ento, apenas este mtodo invocado, sem conhecer a classe que ser
retornada por ele. Por isso, este padro chamado de Factory Method (traduzindo:

mtodo-fbrica): um mtodo responsvel pela fabricao de um objeto
(GAMMA, HELM, et al., 2000).
Aplicabilidade
Sugestes para o uso desse padro (GAMMA, HELM, et al., 2000):
2. Quando uma classe no pode antecipar ou conhecer a classe dos objetos que
deve criar;
3. Quando uma classe quer suas subclasses para especificar os objetos que cria;
4. Quando classes delegam responsabilidade alguma das vrias subclasses
ajudantes, e deseja-se localizar qual a subclasse ajudante acessada.
Estrutura

Figura 5: Estrutura do padro Factory Method
Participantes
Creator. Declara o factory method (mtodo de fabricao) que retorna o objeto
da classe Product (produto). Este elemento tambm pode definir uma
implementao bsica que retorna um objeto de uma classe ConcreteProduct
(produto concreto) bsica;
ConcreteCreator. Sobrescreve o factory method e retorna um objeto da classe
ConcreteProduct;
Product. Define uma interface para os objectos criados pelo factory method;
ConcreteProduct. Uma implementao para a interface Product.
Consequncias
Vantagens:
Elimina a necessidade de acoplar classes especficas para aplicao em
nvel de cdigo (GAMMA, HELM, et al., 2000) na programao, se
lida apenas com a superclasse ou interface, para conhecer os mtodos e

atributos de uma forma genrica, o que permite manipular as subclasses
ou implementaes de maneira particular.
D maior flexibilidade para as classes criar objetos numa classe que
possui o mtodo-fbrica sempre mais flexvel que faz-lo em
separado, assim o mtodo-fbrica funciona como uma conexo para
que uma das subclasses possa prover uma verso estendida de um objeto.
Desvantagem:
Em alguns casos, pode ser criada uma relao superclasse-subclasse para
a criao de classes que suportam o mtodo-fbrica, e de acordo com a
classe a ser criada, uma das vrias subclasses podem sobrescrever o
mtodo-fbrica, a fim de conectar hierarquias de classes paralelas e
fornecer maior portabilidade (GAMMA, HELM, et al., 2000).
Entretanto, esta uma soluo vivel se, e somente se, a especializao
da classe do mtodo fbrica no for estritamente necessria (como no
caso de um nmero elevado de implementaes diferentes para o
mtodo-fbrica). Caso contrrio, a relao custo-planejamento-
implementao de se especializar uma classe apenas para instanciar um
objeto de uma subclasse de outra superclasse pode se revelar bastante
improdutiva, podendo-se optar por uma alternativa mais simples como a
criao classes para o mtodo-fbrica em separado
Exerccio prtico 3

Figura 6: UML do Exemplo 3
Implementao

/**
* Abstrao de uma Aplicao capaz de manipular
* documentos.
*/
abstract class Aplicacao {


private Documento doc;

/**
* Abstrao do Factory Method
*/
abstract Documento criaDocumento();

void novoDocumento() {
this.doc =this.criaDocumento();
}

void abrirDocumento() {
this.doc.abrir();
}
}

/**
* Abstrao de um Documento.
*/
abstract class Documento {

void abrir() {
System.out.println("Documento:Abrir documento!");
}

void fechar() {
System.out.println("Documento:Fechar documento!");
}

void gravar() {
System.out.println("Documento:Gravar documento!");
}
}

/**
* Esta classe concreta contm a implementao
* de uma aplicao capaz de manipular documentos
* do tipo MeuDocumento.
*/
class MinhaAplicacao extends Aplicacao {

/**
* Uma implementao do Factory Method. Este mtodo
* especializado na criao de documentos do tipo MeuDocumento
*/
Documento criaDocumento() {
return new MeuDocumento();
}
}

/**
* Esta classe concreta contm a implementao
* de um tipo de documento especfico.
*/
class MeuDocumento extends Documento {
private String word ="Word";
private String excel="Excel";
}
/* testde Factory Method */
public class FactoyMethodTest {
MinhaAplicacao aplicacao =new MinhaAplicacao();
Documento docu =aplicacao.criaDocumento();
docu.abrir();
//
MeuDocumento documento =new MeuDocumento();
System.out.println(" Documento: "+documento.getWord());
}
}


Exerccios 3.
1. Implemente a aplicao mostrada na figura 7 abaixo usando Factory Method
para criar os objetos.
2. Crie um objeto construtor para cada tipo de objeto (XXXFactory para criar
figuras do tipo XXX)
3. Utilize a fachada Figura, onde os construtores so guardados, e um mtodo
esttico que seleciona o construtor desejado com uma chave.

Figura 7: Exerccio a ser implementado
2.1.4 Padro Prototype
Propsito
Especificar os tipos de objetos a serem criados, usando uma instncia
prototpica, criando novos objetos atravs da cpia desse prottipo. Substituir a gerao
de instncias no-inicializadas de uma classe, fornecendo novos objetos a partir de uma
classe-exemplo.
Motivao
A criao de classes se faz mais simples quando possvel partir de um
exemplo, para ento criar as especializaes condizentes com as necessidades do
domnio da aplicao. Uma alternativa criar classes especializadas que herdem, ou
seja, que sejam subclasses, de uma classe com atributos e mtodos mais genricos (ou
at mesmo uma classe abstrata) com parmetros de visibilidade acessveis, alterando-os
apenas quando for preciso na criao da classe especializada.
Entretanto, essa alternativa apresenta um problema de ordem prtica: a gerao
excessiva de classes especializadas (ou subclasses), para cada necessidade especfica,
pode inchar o sistema, fazendo com que essas classes sempre sejam carregadas,
mesmo que o seu uso seja reduzido. Ainda, tratando-se de visibilidade, para a criao de
subclasses, estas devem conhecer a superclasse que lhes fornecer as caractersticas
comuns a elas, para que, ento, sejam diferenciadas, segundo as necessidades de cada
objeto.
Para sistemas remotos, nem sempre isso possvel: na maioria das situaes, um
servidor de classes fica isolado dos clientes, e estes no podem conhecer a estrutura da

superclasse; apenas podem saber dos parmetros a serem informados em chamadas de
mtodos que participam da criao de produtos (que no caso, seriam as subclasses).
Nesse contexto, Prototype se dispe a simplificar a criao de novas classes a
partir de uma classe-exemplo, copiando-a fielmente, para que, nessa cpia, sejam feitas
as especializaes intrnsecas a cada dependncia da aplicao. Alm de reduzir
sensivelmente o nmero de classes o uso desse padro isola o usurio da estrutura do
objeto, ou a classe-exemplo de seus produtos o que ainda facilita a criao de novas
classes-exemplo, quando for estritamente necessrio.
Aplicabilidade
O padro Prototype pode ser utilizado em sistemas que precisam ser
independentes da forma como os seus componentes so criados, compostos e
representados. O padro Prototype pode ser til em sistemas com as seguintes
caractersticas:
Sistemas que utilizam classes definidas em tempo de execuo;
Sistemas que utilizam o padro Abstract Factory para criao de objetos. Neste
caso, a hierarquia de classes pode se tornar muito complexa e o padro Prototype
pode ser uma alternativa mais simples, por realizar a mesma tarefa com um
nmero reduzido de classes;
Sistemas que possuem componentes cujo estado inicial possui poucas variaes e
onde conveniente disponibilizar um conjunto pr-estabelecido de prottipos que
do origem aos objetos que compem o sistema.
Quando as classes para instanciao so especificadas em tempo de execuo ou
carregadas dinamicamente;
Para evitar a construo de uma hierarquia de classes-exemplo estritamente
especializada ou demasiadamente ligada a um tipo de produto;
Quando as instncias de uma classe podem ter apenas uma ou poucas maneiras de
manifestar seu estado.
Estrutura

Figura 8: Estrutura UML do padro Prototype

Participantes
Prototype. Uma classe que declara uma interface para objetos capazes de clonar
a si mesmo;
PrototypeConcreto. Implementao uma operao para clonar a si prprio.
Cliente. Cria um novo objeto atravs de um prottipo que capaz de clonar a si
mesmo.
Consequncias
Vantagens:
Isolamento entre os produtos (subclasses ou implementaes) e suas classes-
exemplo; esta vantagem se d por dois fatores:
o Facilita a criao de novas classes-exemplo quando for
devidamente necessrio menos acopladas, o que apropriado para
classes que diferem apenas em seus atributos, mas no em seus
comportamentos;
o Fornece de forma transparente e independente acesso ao sistema,
apenas pelo conhecimento dos parmetros necessrios para a criao
das cpias, a partir das classes exemplo.
Reduo do nmero de subclasses: as cpias podem suprir as especializaes
sejam elas por herana ou por implementao de interfaces pois uma vez
criadas com um formato padro, podem ser modificadas dentro de cada
contexto e necessidade inerentes aplicao.
Configurao para o carregamento dinmico de novas classes: com este
padro, possvel configurar a instanciao de classes que originalmente no
estavam ligadas ao programa, pois ao invs de invocar um construtor
esttico, d suporte criao de instncias em tempo de execuo, assim que
sua respectiva classe carregada.
Desvantagem:
A nica desvantagem encontrada foi a da utilizao do mtodo Clone:
o Este mtodo cria uma cpia exata de um objeto que lhe for passado como
parmetro. Uma cpia exata carrega consigo uma espcie de fotografia
do objeto: no apenas seu comportamento clonado, mas tambm seu
estado, ou seja, um novo objeto com os mesmos campos do objeto
original;
o Entretanto, quando se quer copiar um objeto, quase sempre se deseja um
novo objeto e no um objeto novo, o que significa uma cpia no
instanciada daquele objeto, ou com os campos ajustados para valores
iniciais, que sejam default para toda a aplicao.
Assim, o programador deve ter em mente esta diferena ao implementar este
padro, pois objetos clonados podem apresentar problemas de incluso de

classes no existentes e/ou referencias circulares (dependncias de parmetros
ou resultados que sejam internos aos objetos e que no sejam levados em
considerao na clonagem).
Exerccio pratico 4

Figura 8: Exemplo do padro Prototype
Implementao

/**
* Prototype class
*/
abstract class Prototype implements Cloneable {
@Override
public Prototype clone() throws CloneNotSupportedException {
return (Prototype)super.clone();
}

public abstract void setX(int x);

public abstract void printX();

public abstract int getX();
}

/**
* Implementation of prototype class
*/
class PrototypeImpl extends Prototype {
int x;

public PrototypeImpl(int x) {
this.x =x;
}
public void setX(int x) {
this.x =x;
}
public void printX() {
System.out.println("Valor :" +x);
}

public int getX() {
return x;
}
}

/**

* Client code
*/
public class PrototypeTest {
public static void main(String args[]) throws CloneNotSupportedException {
Prototype prototype =new PrototypeImpl(1000);

for (int i =1; i <10; i++) {
Prototype tempotype = prototype.clone();

// Usage of values in prototype to derive a new value.
tempotype.setX( tempotype.getX() * i);
tempotype.printX();
}
}
}

Exerccio 4.
1. Elabore um programa para exercitar a criao do padro Prototype:
a. O Cliente um revendedor de automveis VW.
b. O (Abstract) Prototype um modelo de automvel GOL.
c. Os ConcretePrototype so modelos de Automveis GOL.
Modelo Luxo.
i. Gol com Motor AP de 250HP e Pneus 13/185.
Modelo Standard.
i. Gol com Motor AP de 180HP e Pneus 13/185.
d. Crie uma aplicao de venda de automveis que vende Gol atravs da clonagem
dos modelos Luxo e Standard
2.1.5 Padro Singleton
Propsito
Padro de projeto simples que ilustra vrias caractersticas necessrias aos
padres de projeto. Classificado criacional, pois est relacionado com processo de
criao de objetos, possuindo inmeras aplicaes e implementao bastante direta.
Tem como propsito garantir a existncia de uma instncia nica de uma classe
especfica, que possa ser acessada de maneira global e uniforme.
Motivao
O que motiva sua existncia que muitas aplicaes necessitam garantir a
ocorrncia de uma instncia de classes especficas, pois tais objetos podem fazer uso de
recursos cuja utilizao deve ser exclusiva, ou porque se deseja que os demais
elementos do sistema compartilhem um nico objeto particular.

Estas situaes ocorrem quando vrios subsistemas utilizam um nico arquivo
de configurao, permitindo sua modificao concorrente. Ou quando s se deve

estabelecer uma conexo exclusiva com um banco de dados ou um sistema remoto,
devendo ser compartilhado por vrias tarefas paralelas; entre muitas outras.
Ao mesmo tempo no se quer que os usurios destas classes zelem por esta
condio de unicidade, mas se deseja oferecer acesso simples instncia nica que
dever existir, portanto se adiciona estas responsabilidades s classes que devero
constituir um Singleton.
Aplicabilidade
Use o padro Singleton quando:
Deve haver uma nica instncia de uma classe e esta deve ser acessada a
partir de um ponto de acesso bem-conhecido.
A instncia nica deve ser extensvel atravs de subclasses e clientes
podem usar instncias diferentes polimorficamente, sem modificao de
cdigo.
Estrutura

Figura 9: Padro UML do Singleton
Participantes
Singleton define uma operao Instance que deixa clientes acessarem sua
nica instncia. Instance uma operao de classe.
Pode ser responsvel para criar sua prpria instncia nica.
Consequncias
Vantagens:
Acesso controlado instncia nica;
O Singleton tem controle sobre como e quando clientes acessam a
instncia;
Espao de nomes reduzido;

O Singleton melhor que variveis globais, j que as globais podem
ser encapsuladas na instncia nica, deixando um nico nome externo
visvel;
Permite refinamento de operaes e de representao;
Vrias classes Singleton (relacionadas ou no via herana) podem
obedecer a mesma interface, permitindo que um Singleton particular seja
escolhido para trabalhar com uma determinada aplicao em tempo de
execuo;
Mais flexvel que mtodos estticos;
Exerccio prtico 5

Figura 10: Exemplo UML do Singleton
Implementao
//
public class Singleton {

private static Singleton instance ==new Singleton();

private Singleton() { }

public static synchronized Singleton getInstance() {
if (instance ==null) {
instance =new Singleton();
}
return instance;
}
}

Exerccio 5
1. Usando o padro singleton implemente uma conexo a um banco de dados.


2.2 PADRES ESTRUTURAIS
Os padres estruturais se preocupam com a forma como classes e objetos so
compostos para formar estruturas maiores. Os padres estruturais de classes utilizam a
herana para compor interfaces ou implementaes. Estes padres so utilizados para
definir a composio de objetos e controlar o acesso aos subsistemas de objetos.
Os exemplos a seguir descrevem os prs e contras dos requisitos do sistema e
como se aplicam aos diferentes padres de projeto estrutural. Em oposio aos padres
arquiteturais que definem completamente uma soluo ou subsistema, em geral existem
vrios padres de projeto estrutural em um nico framework.
2.2.1 Padro Adapter
Propsito
Converter a interface de uma classe em outra interface, esperada pelos clientes.
O Adapter permite que classes com interfaces incompatveis trabalhem em conjunto. O
padro Adapter facilita a converso da interface de uma classe para outra interface mais
interessante para o cliente, fazendo com que vrias classes possam trabalhar em
conjunto independentemente das interfaces originais.
Motivao
O Adapter utilizado quando uma classe j existente e sua interface no
combinam com a esperada pelo cliente ou se se deseja criar uma classe reutilizvel que
coopera com classes no relacionadas ou no previstas, ou seja, classes q no
necessariamente tenham interfaces compatveis, entre outras utilizaes. O padro
Adapter tem finalidade estrutural e abrange tanto escopo de classe quanto de objeto, por
isso existe o adaptador de classe e o adaptador de objetos, o primeiro utilizado quando
o alvo uma interface, consequentemente usa herana mltipla, o segundo utilizado
quando o alvo uma classe e faz uso da agregao.

Fig. 11: Padro Adapter

Aplicabilidade
Use o padro Adapter quando:
Voc quiser usar uma classe existente, mas sua interface no corresponde
interface de que necessita.
Voc quiser criar uma classe reutilizvel que coopera com classes no
relacionadas ou no previstas, ou seja, classes que no necessariamente
tenham interfaces compatveis.
(Somente para adaptadores de objetos) voc necessitar de usar variveis
subclasses existentes, porm, for impraticvel adaptar estas interfaces
criando subclasses para cada uma. Um adaptador de objeto pode adaptar a
interface da sua classe-me.
Estrutura
Um adaptador de classe usa a herana mltipla para adaptar uma interface
outra.

Fig 12: Padro Adapter herana mltipla
Um adaptador de objeto depende da composio de objetos.

Fig. 13: Padro Adapter composio de objetos
Participantes
Target (Alvo). Define a interface especifica do domnio que o Cliente
usa.

Client (Cliente). Colabora com objetos compatveis com a interface de
Target.
Adaptee(ClasseExistente). Define uma interface existente que necessita
ser adaptada.
Adapter (Adaptador). Adapta a interface do Adaptee interface de
Target.
Consequncias
Os adaptadores de classes e de objetos tm diferentes solues de compromisso.
Um adaptador de classe:
(herana) adapta Adaptee a Target atravs de uma classe Adapter concreta. Em
consequncia, no funciona quando se deseja adaptar uma classe e todas as suas
subclasses.
Adapter pode sobrescrever alguns dos comportamentos de Adaptee, uma vez
que um a subclasse de Adaptee.
Introduz apenas um objeto, e no necessrio endereamento indireto adicional
por ponteiros para chegar at o adaptee.
Um adaptador de objetos:
Um nico Adapter funciona com muitos Adaptees, isto , o prprio Adaptee e
todas as suas subclasses (se existirem).
O Adapter tambm pode adicionar funcionalidade a todos os adaptees a cada
vez.
difcil sobrescrever o comportamento do Adaptee. Seria necessrio derivar
Adaptee e fazer o Adapter referir-se a subclasse ao invs do prprio Adaptee.
Exemplo prtico 6

Fig. 14: Exemplo UML do padro Adapter

Implementao
public interface FileManager {
public String open(String s);
public String close();
public String read(int pos, int amount, byte[] data);
public String write(int pos, int amount, byte[] data);
}
FileManager.java
public class FileManagerUtil {
private RandomAccessFile f;
public boolean openFile(String fileName) {
System.out.println("Opening file: "+fileName);
boolean success=true;
return success;
}
public boolean closeFile() {
System.out.println("Closing file");
return success;
}
public boolean writeToFile(String d, long pos, long amount) {
System.out.print("Writing "+amount+
" chars from string: "+d);
System.out.println(" to pos: "+pos+" in file");
return success;
}
public String readFromFile(long pos, long amount) {
System.out.print("Reading "+amount+
" chars from pos: "+pos+" in file");
return new String("dynamite");
}
}
FileManagerUtil.java
public class FileManagerImpl extends FileManagerUtil implements
FileManager {
public String close() {
return new Boolean(closeFile()).toString();
}
public String open(String s) {
return new Boolean(openFile(s)).toString();
}
public String read(int pos, int amount, byte[] data) {
return readFromFile(pos, amount);
}
public String write(int pos, int amount, byte[] data) {
boolean tmp=writeToFile(new String(data), pos, amount);
return String.valueOf(tmp);
}
}
FileManagerImpl.java
public class FileManagerClient {
FileManager f =null;
String dummyData ="dynamite";
f =new FileManagerImpl();
System.out.println("Using filemanager: "+
f.getClass().toString());
f.open("dummyfile.dat");
f.write(0, dummyData.length(), dummyData.getBytes());
String test =f.read(0,dummyData.length(),
dummyData.getBytes());
System.out.println("Data written and read: "+test);
f.close();
}
}
FileManagerClient.java


Exerccios 6.
1. Complete o diagrama de classes abaixo para que um objeto TextView possa
participar da aplicao DrawingEditor.

2. J ustifique sua escolha pelo tipo de Adapter usado (de classe ou de objeto).
3. Escreva uma classe que permita que o cliente VectorDraw, que j usa a classe
Shape, use as operaes de RasterBox (e Coords) para obter os mesmos dados,
como mostrado na figura a seguir.

2.2.2 Padro Bridge
Propsito
Desacoplar a abstrao da sua implementao, de modo que as duas possam
variar independentemente.
Motivao
Uma abstrao pode ter uma entre varias implementaes possveis, a
maneira usual de acomod-las usando herana. O uso da herana para

permitir diversas implementaes de uma abstrao pode no ser
suficientemente flexvel.
Interface e implementao ficam definitivamente ligadas e no podem ser
usadas de modo independente.
Modificar a abstrao afeta em geral as implementaes, por exemplo: um
cdigo cliente deve ser capaz de criar um cdigo de uma janela, sem se
comprometer com um tipo especfico de janela (e.g., Xwindow, IBM
Presentation Manager, etc.).
O padro Bridge cria uma hierarquia para as interfaces de janela e uma
hierarquia para cada implementao de janela especfica de uma
plataforma. A segunda hierarquia deriva de uma classe raiz WindowImp.

Fig. 15: Padro Bridge

Aplicabilidade
Use o padro Bridge quando:
Desejar evitar um conexo permanente entre abstrao e implementao.
Para estender abstraes e suas implementaes atravs de subclasses de modo
independente.
Para evitar que mudanas na implementao atinjam os clientes.
Para evitar proliferao de classes (muitas classes de diferentes artefatos para
diferentes ambientes em uma nica hierarquia).
Deseja compartilhar uma implementao entre mltiplos objetos.

Estrutura

Participantes
Abstrao. Define a interface da Abstrao.
Abstrao Concreta. Estende a interface definida por Abstrao.
Implementador. Define a interface para as classes de implementao. Esta
interface no precisa corresponder exatamente interface de Abstrao; de fato,
as duas interfaces podem ser bem diferentes. A interface de Implementador
fornece somente operaes primitivas e Abstrao define operaes de nvel
mais alto baseado nestas primitivas.
Implementador Concreto. Implementa a interface de Implementador e define
sua implementao concreta.
Consequncias
Separa interface de implementao.
Melhora a extenso de hierarquias de abstrao e implementao (evoluo
independente).
Esconde detalhes de implementao dos clientes.
Implementao
Apenas um Implementor:
o um caso degenerado do Bridge;
o no precisa criar uma classe Implementor abstrata;
o ainda assim til por separar interface da implementao;
Quando, como e onde decidir qual classe Implementor deve ser instanciada?
o no construtor da abstrao, se ela conhece todas as implementaes;
(possivelmente com base em parmetros passados ao construtor)
Usar uma implementao default cambivel com o uso;
Usar uma AbstractFactory.

Exemplo prtico 7

/** "Abstraction" */
public interface Shape {
public void draw();
public void resizeByPercentage(double pct);
}
Shape.java
/** "Refined Abstraction" */
public class CircleShape implements Shape {
private double x, y, radius;
private DrawingAPI drawingAPI;
public CircleShape(double x, double y, double radius, DrawingAPI
drawingAPI) {
this.x =x;
this.y =y;
this.radius =radius;
this.drawingAPI =drawingAPI;
}
// Implementation specific
public void draw() {
drawingAPI.drawCircle(x, y, radius);
}
// Abstraction specific
public void resizeByPercentage(double pct) {
radius *=pct;
}
}
CircleShape.java
/** "Implementor" */
public interface DrawingAPI {
public void drawCircle(double x, double y, double radius);
}
DrawingAPI.java
/** "ConcreteImplementor" 1/2 */
public class DrawingAPI1 implements DrawingAPI {
public void drawCircle(double x, double y, double radius) {
System.out.printf("API1.circle at %f:%f radius %f\n", x, y,
radius);
}
}
DrawingAPI1.java
/** "ConcreteImplementor" 2/2 */
public class DrawingAPI2 implements DrawingAPI {
public void drawCircle(double x, double y, double radius) {
System.out.printf("API2.circle at %f:%f radius %f\n", x, y,
radius);
}
}
DrawingAPI2.java
public class BridgeExample {
Shape[] shapes =new Shape[2];
shapes[0] =new CircleShape(1, 2, 3, new DrawingAPI1());

shapes[1] =new CircleShape(5, 7, 11, new DrawingAPI2());
for (Shape shape : shapes) {
shape.resizeByPercentage(2.5);
shape.draw();
}
}
}
BridgeExample.java

Exerccios
1. Considere a hierarquia abaixo.

Ser necessrio criar uma subclasse FIFOQueue como mostrado na figura a seguir

O que pode ser feito? (Escolha a melhor alternativa e use, se possvel, classes da
API J ava).
2. Faa um Bridge usando a classe java.util.List como soluo de implementao.
Implemente os mtodos queue(), dequeue(), size() e isEmpty().

2.2.3 Padro Composite
Propsito
Compor objetos em estruturas de rvore para representar hierarquias todo-parte.
Composite permite que clientes tratem objetos individuais e composies de objetos de
maneira uniforme.
Motivao
Aplicaes grficas, tais como editores de desenhos e sistemas de captura
esquemtica, permitem aos usurios construir diagramas complexos a partir de
componentes simples.

Permitir que objetos do tipo todo ou do tipo parte sejam tratados da mesma
maneira. No projeto de um sistema de arquivos, espera-se que tanto um arquivo quanto
um diretrio possam informar o seu tamanho.

Aplicabilidade
Use o padro Composite quando:
Para representar hierarquia partes-todo de objetos;
Quando os clientes sejam capazes de ignorar a diferena entre composies
de objetos e objetos individuais. Os clientes trataro todos os objetos na
estrutura composta de maneira uniforme.
Estrutura

Participantes
Component (Componente):
o Declara a interface para os objetos na composio;
o Implementa comportamento default comum;
o Declara uma interface para acessar e gerenciar seus componentes filhos;
Leaf (Folha):

o Representa objetos folha na composio;
o Define comportamento para objetos primitivos na composio;
Composite (Composio):
o Define componentes para objetos que tm filhos;
o Armazena os componentes-filho;
o Implementa as operaes relacionadas com os filhos presentes na
interface de Component.
Client (Cliente):
o Manipula objetos na composio atravs da interface de Component.
Consequncias
O padro composite:
Define hierarquias de classe que consistem de objetos primitivos e objetos
compostos;
Estruturas compostas e objetos individuais so tratados de maneira uniforme
pelo cliente;
Facilita adicionar novos tipos de componentes;
Pode tornar o projeto excessivamente genrico.
Implementao
H muitos aspectos a serem considerados quando se implemente este padro:
Referncias explcitas aos pais;
Compartilhamento de componentes;
Maximizao da interface de Component;
Declarando as operaes de gerncia de filhos;
Component deveria implementar uma lista de Components?
Ordenao dos filhos;
Uso de caching para melhorar o desempenho;
Quem deveria deletar componentes?
Qual a melhor estrutura de dados para o armazenamento de componentes?
Exemplo prtico 8
public interface AbstractFile {
public void ls();
}
AbstractFile.java
public class Directory implements AbstractFile {
private String name;
private ArrayList<AbstractFile>files =new
ArrayList<AbstractFile>();
private Indentation indentation;
public Directory (String name, Indentation indentation) {
this.name =name;
this.indentation =indentation;
}
public void add(AbstractFile f) {

files.add(f);
}
public void ls() {
System.out.println(indentation.getIndentation() +name);
indentation.increaseIndentation();
for (AbstractFile file : files) {
file.ls();
}
indentation.decreaseIndentation();
}
}
Directory.java
class File implements AbstractFile {
private Indentation indentation;
public File(String name, Indentation indentation) {
this.name =name;
this.indentation =indentation;
}
public void ls() {
System.out.println(indentation.getIndentation() +
name);
}
}
File.java
public class Indentation {
private StringBuffer sbIndent =new StringBuffer();
public String getIndentation() {
return sbIndent.toString();
}
public void increaseIndentation() {
sbIndent.append(" ");
}
public void decreaseIndentation() {
if (sbIndent.length() >=3) {
sbIndent.setLength(sbIndent.length() - 3);
}
}
}
Indentation.java
public class ClientComposite {
Indentation indentation =new Indentation();
Directory dirOne =new Directory("dir111", indentation);
Directory dirTwo =new Directory("dir222", indentation);
Directory dirThree =new Directory("dir333", indentation);
File a =new File("a", indentation);
File b =new File("b", indentation);
File c =new File("c", indentation);
File d =new File("d", indentation);
File e =new File("e", indentation);
dirOne.add(a);
dirOne.add(dirTwo);
dirOne.add(b);
dirTwo.add(c);
dirTwo.add(d);
dirTwo.add(dirThree);
dirThree.add(e);
dirOne.ls();
}
}
ClientComposite.java

Exerccios
1. Complete o cdigo que falta no exemplo mostrado na figura a seguir.



2. Que padro (es) voc usaria para resolver o problema abaixo?
O congresso inscreve os participantes, que podem ser um indivduo ou
uma instituio. Cada indivduo tem um assento.

Mostre como implementar uma soluo.
3. Implemente o padro Composite:
a. Escreva uma interface Publicao que trate de forma equivalente
colees (compostas de outras publicaes, como revistas, jornais,
cadernos) e artigos individuais indivisveis.
b. Escreva uma aplicao de testes que construa o diagrama de objetos a
seguir e


Imprima o nmero de publicaes e de artigos
Imprima o contedo de toString() que deve imprimir o toString
de cada publicao (deve conter o nome e, se for artigo, o autor).
2.2.4 Padro Decorator
Propsito
Anexar responsabilidades adicionais a um objeto dinamicamente. Os Decorators
oferecem uma alternativa flexvel ao uso de herana para estender uma funcionalidade
Motivao
Adicionar responsabilidades a objetos individuais, e no a toda uma classe. Por
exemplo, adio de propriedades, como bordas, ou comportamentos, como rolamento, a
componentes de uma interface de usurio, apenas quando for necessrio. Uma classe
TextView mostra um texto em uma janela, queremos incrementar a janela com uma
borda e/ou uma barra de rolagem, pode-se usar herana, mas muitas subclasses
incrementos no podem ser acrescentados/removidos em execuo.
Aplicabilidade
Use Decorator:
Para adicionar responsabilidades a objetos individuais de forma dinmica e
transparente, isto , sem afetar outros objetos.
Para retirar responsabilidades.
Quando a extenso atravs do uso de subclasses no pratica. s vezes, um
grande nmero de extenses independentes possvel e isso poderia produzir
uma exploso de subclasses para suportar cada combinao. Ou a definio de
uma classe oculta ou indisponvel para utilizao de subclasses.
Estrutura


Participantes
Componente: define a interface para objetos que podem ter responsabilidades
acrescentadas dinamicamente;
ComponenteConcreto: define um objeto para o qual responsabilidades
adicionais podem ser atribudas;
Decorador: define uma interface que segue a de Componente e mantm uma
referncia para um objeto Componente;
DecoradorConcreto: acrescenta responsabilidades ao componente.
Consequncias
Maior flexibilidade que herana: decoradores podem ser retirados e
acrescentados em execuo, Mas ponteiros para a TextView continuam
enxergando o objeto sem decorao.
No h necessidade de criao de inmeras subclasses.
Um decorador e seus componentes no so iguais: operaes de igualdade
falham.
Muitos objetos pequenos so criados.
Implementao
Vrios tpicos deveriam ser levados em conta quando se aplica o padro Decorator.
Conformidade de interface;
Omisso da classe abstrata Decorator;
Mantendo leves as classes Component;
Mudar o exterior de um objeto versus mudar o seu interior (Decorator versus
Strategy ).
Exemplo prtico 9


public interface Logger {
public void log(String msg);
}
Logger.java
public class LoggerDecorator implements Logger {
Logger logger;
public LoggerDecorator(Logger logger) {
super();
this.logger =logger;
}
public void log(String msg) {
logger.log(msg);
}
}
LoggerDecorator.java
public class ConsoleLogger implements Logger {
System.out.println("Detta ska skrivas till consolen! "+
msg);
}
}
ConsoleLogger.java
public class EncryptLogger extends LoggerDecorator {
public EncryptLogger(Logger logger) {
super(logger);
}
msg =encrypt(msg);
logger.log(msg);
}
private String encrypt(String msg) {
msg =msg.substring(msg.length()-1) +msg.substring(0,
msg.length() -1);
return msg;
}
}
EncryptLogger.java
public class HTMLLogger extends LoggerDecorator {
public HTMLLogger(Logger logger) {
super(logger);
}
msg =makeHTML(msg);
logger.log(msg);
}
private String makeHTML(String msg) {
msg ="<html><body>" +"<b>" +msg +"</b>" +
"</body></html>";
return msg;
}
}
HTMLLogger.java
public class LoggerFactory {
public static final String TYPE_CONSOL_LOGGER ="console";
public static final String TYPE_FILE_LOGGER ="file";
public Logger getLogger(String type) {
if(TYPE_CONSOL_LOGGER.equals(type)) {
return new ConsoleLogger();
}else {
return new FileLogger();
}
}
}
LoggerFactory.java
public class FileLogger implements E1Logger{
System.out.println("Dentro do FileLogger! "+msg);
}
}
FileLogger.java
public class DecoratorClient {

LoggerFactory factory =new LoggerFactory();
Logger logger =
factory.getLogger(LoggerFactory.TYPE_FILE_LOGGER);
HTMLLogger htmlLogger =new HTMLLogger(logger);
htmlLogger.log("A message to log");
EncryptLogger encryptLogger =new EncryptLogger(logger);
encryptLogger.log("A message to log");
}
}
DecoratorClient.java

Exerccios
1. Crie um objeto simples que armazene um texto que possa ser recuperado com
um mtodo getTexto(). Crie decoradores que retornem o texto: a) em caixa-alta,
b) invertido e c) cercado por tags <b> e </b>. Teste os decoradores
individualmente e em cascata.
2. Crie um decorador ComandoReader que possa decorar um Reader. O objeto no
deve alterar o comportamento dos mtodos read() originais mas deve oferecer
um mtodo readComando() que retorna um objeto Command
O objeto Command deve ser construdo a partir do stream recebido. Podem
ser cinco tipos: NullCommand, NewCommand, DeleteCommand,
GetCommand e GetAllCommand
Os strings de entrada devem vir no formato <comando><um ou mais
espaos em branco><argumentos>. O nmero de argumentos esperados
depende do comando: 1) new id nome, 2) delete id, 3) get id, 4) all.
Comandos incorretos ou desconhecidos retornam NullCommand.
3. Teste o ComandoReader passando-lhe um stream de caracteres (leia um string
como um stream).
2.2.5 Padro Faade
Propsito
Oferecer uma interface nica para um conjunto de interfaces de um subsistema.
Faade define uma interface de nvel mais elevado que torna o subsistema mais fcil de
usar.
Motivao
Necessidade de estruturar um sistema em subsistema, facilitando o acesso e
minimizando a comunicao e dependncias entre os subsistemas.
Aplicabilidade
Use padro Faade quando:

Fornecer uma interface simples e unificada para um sistema complexo,
desacopla os subsistemas dos clientes, promovendo-se a independncia e
portabilidade dos subsistemas, estruturando o sistema em camadas.
Estruturar um sistema em subsistemas ajuda a reduzira complexidade. Um
objetivo comum a todos os projetos minimizar a comunicao e as
dependncias entre os subsistemas que compem uma aplicao. Uma maneira
de alcanar este objetivo introduzir um objeto faade (fachada)
Existem muitas dependncias entre os clientes e as classes de implementao de
uma abstrao. Ao introduzir uma faade para desacoplar o subsistema dos
clientes e de outros subsistemas, se promove a independncia e portabilidade
dos sistemas.
Estrutura

Participantes
Faade. Conhece quais as classes do subsistema responsveis pelo atendimento
de uma solicitao.
Classes de subsistema. Implementa a funcionalidade do subsistema. Encarrega-
se do trabalho atribudo a elas pelo objeto Faade. No tem conhecimento da
Faade, isto , elas no mantm referncias para a mesma.
Consequncias
O padro Faade oferece os seguintes benefcios:
Isola os clientes dos componentes de um subsistema, reduzindo o nmero de
objetos com os quais os clientes tm que lidar, e tornando, assim, mais fcil o
uso de tal subsistema.

Promove o fraco acoplamento entre um subsistema e os seus clientes. Esta
caracterstica permite variar os componentes de um subsistema sem afetar os
seus clientes. Simplifica o porte de um sistema para outras plataformas, uma vez
a sua utilizao diminui a ocorrncia de alteraes em cascata em funo da
necessidade de uma alterao em certo subsistema.
No impede que as aplicaes utilizem diretamente as classes de um subsistema
caso necessitem faz-lo. Assim, pode-se escolher entre a facilidade de uso e uma
maior flexibilidade na manipulao das funcionalidades fornecidas por um
subsistema.
Implementao
Considere os seguintes aspectos quando implementar uma faade:
Reduo do acoplamento cliente-subsistema. O acoplamento entre os clientes e
o subsistema pode ser ainda mais reduzido tornando Fade uma classe abstrata
com subclasses concretas para diferentes implementaes de um subsistema.
Classes de subsistemas: pblicas e privadas?
Exemplo prtico 10
public class Cubo {
public int returnCubo(int x){
return x * x * x;
}
}
Cubo.java
public class Duplica {
public int returnDouble(Cubo cubo, int x) {
return 2 * cubo.returnCubo(x);
}
}
Duplica.java
public class Facade {
public int cubeX(int x) {
Cubo cubo =new Cubo();
return cubo.returnCubo(x);
}
public int cubeXTimes2(int x) {
Duplica duplica =new Duplica();
return duplica.returnDouble(cubo, x);
}
public int xToSixthPowerTimes2(int x) {
Duplica duplica =new Duplica();
DuplicaSixPower six =new DuplicaSixPower();
return six.doMoreStuff(cubo, duplica, x);
}
}
Facade.java
public class DuplicaSixPower {
public int doMoreStuff(Cubo cubo, Duplica doble, int x) {
return cubo.returnCubo(x)*doble.returnDouble(cubo, x);
}
}
DuplicaSixPower.java
public class ClienteFacade {
Facade facade =new Facade();


int x =3;
System.out.println("O Cubo de " +x +" =" +facade.cubeX(3));
System.out.println("O Cubo de " +x +" multiplicando por 2 =" +facade.cubeXTimes2(3));
System.out.println(x + " elevado a sexta potencia multiplicado por 2 = " +
facade.xToSixthPowerTimes2(3));
}
}
ClienteFacade.java

Exerccios
1. A aplicao abaixo tem uma GUI. Ser necessrio implementar uma UI
orientada a caracter e uma interface Web. O que poderia ser usado para reduzir a
duplicao de cdigo e tornar a utilizao das classes envolvidas mais simples?
Implemente!

2. Qual a diferena entre Faade e Adapter (se voc tiver um Faade para um nico
objeto?)
2.2.6 Padro Flyweight
Propsito
Usar compartilhamento para suportar grandes quantidades de objetos refinados
eficientemente.
Motivao
Em um editor de textos certas vantagens so obtidas ao representar cada
caractere como objeto.
Entretanto, seria necessria a instanciao de um nmero consideravelmente alto
de objetos, com consumo excessivo de memria e overhead de execuo.
Um flyweight um objeto compartilhado que pode ser utilizado
simultaneamente em mltiplos contextos.

Atua como um objeto independente em cada contexto, de modo que os clientes
no so cientes do compartilhamento.
O conceito chave a distino entre estado intrnseco e estado extrnseco:
o O estado intrnseco armazenado no flyweight e consiste de informaes
independentes do contexto e, portanto, compartilhveis.
o O estado extrnseco depende de e varia com o contexto e, portanto, no
pode ser compartilhado. Os clientes so responsveis por passar o estado
extrnseco para o flyweight, quando necessrio.
Aplicabilidade
A eficincia do padro Flyweight depende muito de como onde ele usado.
Aplique o padro Flyweight quando todas as condies a seguir forem verdadeiras:
A aplicao usa um grande nmero de objetos.
Custos de armazenamento so altos devido ao grande nmero de objetos.
O estado da maior parte dos objetos pode ser definido de forma extrnseca.
Se o estado extrnseco for removido muitos grupos de objetos podem ser
substitudos por um nmero relativamente pequeno de objetos compartilhados.
A aplicao no depende da identidade dos objetos. Uma vez que objetos
Flyweights podem ser compartilhados, testes de identidade retornaro
verdadeiro para objetos conceitualmente diferentes.
Estrutura

Participantes

Flyweight: Declara uma interface atravs da qual Flyweights podem receber
estado extrnseco e atuar com base nele.
ConcreteFlyweight (Caractere): Implemente a interface Flyweighte adiciona o
armazenamento do estado intrnseco, se existir. O objeto deve ser compartilhvel
qualquer estado que ele armazenar deve ser independente do contexto do
ConcreteFlyweight.
UnsharedConcreteFlyweight (Row, Column): Nem todas as subclasses de
Flyweightprecisam ser compartilhadas. comum que objetos
UnsharedConcreteFlyweight contenham, como filhos, objetos
ConcreteFlyweightde algum nvel da hierarquia de Flyweights.
FlyWeightFactory: Cria e gerencia objetos Flyweight. Garante que os
Flyweights so compartilhados de forma apropriada. Quando o cliente solicita
um Flyweight ele devolve um j existente ou cria um novo.
Client: Mantm referncias a Flyweights. Calcula ou armazena o estado
extrnseco dos Flyweights.

Consequncias
Podem adicionar custos de runtime, devido transferncia, descoberta ou
computao do estado extrnseco.
Tais custos so, entretanto, compensados pelas economias no armazenamento,
que influenciado por alguns fatores:
o Reduo do nmero total de instncias propiciada pelo
compartilhamento.
o Tamanho do estado intrnseco por objeto.
o Forma de obteno do estado extrnseco (armazenado ou calculado).
Quanto maior o compartilhamento maior a economia no armazenamento.
Quanto maior o tamanho do estado intrnseco (compartilhado) do objeto maior a
economia no armazenamento.
Esta economia ainda maior quando o estado extrnseco computado ao invs
de armazenado.
Implementao
Considere os seguintes aspectos ao implementar o padro Flyweight:
Reduzindo o estado extrnseco:
o Remover estado extrnseco no ir ajudar a reduzir o custo de
armazenamento se existir tantos tipos diferentes de estado quanto o
nmero de instncias antes do compartilhamento
o O estado extrnseco pode ser computado a partir de uma estrutura
separada, com menores demandas de armazenamento:

Ex: A fonte e o estilo de cada caracter do texto podem ser
armazenados em um mapa separado que rastreia os caracteres
com os mesmos atributos tipogrficos.
Como os textos utilizam uma quantidade menor de fontes e
estilos do que caracteres diminui-se a demanda por
armazenamento.
Gerenciando objetos compartilhados:
o Clientes no devem instanciar objetos diretamente e sim atravs do
FlyweightFactory.
o Geralmente a fbrica utiliza um container associativo (ex: mapa cuja
chave o caractere e o valor o Flyweight).
o Pode ser necessrio reference counting ou garbage collection quando o
nmero de Flyweightsno fixo e no pequeno.

Exemplo prtico 11
public interface Flyweight {
public void doMath(int a, int b);
}
Flyweight.java
public class FlyweightAdder implements Flyweight {
String operation;
public FlyweightAdder() {
operation ="Somando";
try {
Thread.sleep(3000);
}catch (InterruptedException e) {
e.printStackTrace();
}
}
@Override
public void doMath(int a, int b) {
System.out.println(operation +" " +a +" +" +b +": " +(a +b));
}
}
FlyweightAdder.java
public class FlyweightMultiplier implements Flyweight {
String operation;
public FlyweightMultiplier() {
operation ="multiplicando";
try {
Thread.sleep(3000);
}catch (InterruptedException e) {
e.printStackTrace();
}
}
@Override
public void doMath(int a, int b) {
System.out.println(operation +" " +a +" * " +b +": " +(a * b));
}
}
FlyweightMultiplier.java
public class FlyweightFactory {
private static FlyweightFactory flyweightFactory;
private Map<String, Flyweight>flyweightPool;
private FlyweightFactory() {
flyweightPool =new HashMap<String, Flyweight>();
}
public static FlyweightFactory getInstance() {

if (flyweightFactory ==null) {
flyweightFactory =new FlyweightFactory();
}
return flyweightFactory;
}
public Flyweight getFlyweight(String key) {
if (flyweightPool.containsKey(key)) {
return flyweightPool.get(key);
}else {
Flyweight flyweight;
if ("add".equals(key)) {
flyweight =new FlyweightAdder();
}else {
flyweight =new FlyweightMultiplier();
}
flyweightPool.put(key, flyweight);
return flyweight;
}
}
}
FlyweightFactory.java
public class ClientFlyweight {
FlyweightFactory flyweightFactory =FlyweightFactory.getInstance();
for (int i =0; i <5; i++) {
Flyweight flyweightAdder =flyweightFactory.getFlyweight("add");
flyweightAdder.doMath(i, i);
Flyweight flyweightMultiplier =
flyweightFactory.getFlyweight("multiply");
flyweightMultiplier.doMath(i, i);
}
}
}
ClientFlyweight.java

Exerccios
1. Implemente uma aplicao que imprima aleatoriamente 10 nmeros de 10
algarismos:
Cada algarismo deve ser uma instancia do objeto Algarismo que contm
o nmero 1, 2, 3, etc. como membro imutvel.
Use Flyweight para construir um cache de objetos para que objetos que
representam o mesmo algarismo sejam reutilizados.
2. Implemente um cache de fatoriais:
Cada fatorial de n equivale a n*fatorial(n-1). Use um cache para
aproveitar fatoriais j calculados.
Escreva uma aplicao que calcule fatoriais de 0 a 15.
2.2.7 Padro Proxy
Propsito
Disponibilizar um substituto para outro objeto, controlando o acesso a ele.
Motivao
Adiar o custo de criao e inicializao de um objeto at o momento em que ele
realmente necessrio.

Ex: um editor de textos pode no carregar todas as imagens do texto no
momento em que ele aberto, somente aqueles atualmente visveis na aplicao.
Cria-se os objetos sob demanda.
Entretanto, o que colocar no lugar da imagem para indicar a sua presena no
texto?
Como se pode abstrair a criao sob demanda da imagem, de modo que o cdigo
da implementao do editor (ex: renderizao e formatao de texto) seja
mantido simples?
A soluo utilizar um objeto procurador (proxy) que atua no lugar da imagem
real.
O proxy cria a imagem real somente quando o editor solicita a sua exibio.
O proxy armazena uma referncia para a imagem e as suas dimenses, de modo
que o algoritmo de formatao funcione mesmo sem conhecer a imagem real.
Aplicabilidade
til sempre que existe a necessidade de uma referncia para objeto que seja
mais sofisticada e verstil do que um ponteiro simples. Alguns exemplos:
o Remote Proxy (Ambassador): disponibiliza um representante local para
um objeto que reside em um espao de endereamento diferente.
o Virtual Proxy: cria objetos custosos sob demanda.
o Protection Proxy: controla o acesso ao objeto original. til quando
objetos precisam ter direitos de acesso diferentes.
til sempre que existe a necessidade de uma referncia para objeto que seja
mais sofisticada e verstil do que um ponteiro simples. Alguns exemplos:
o Smart Reference (Smart Pointers): alternativa aos ponteiros
convencionais, realizando aes adicionais no momento em que o objeto
acessado. Por exemplo:
Contagem do nmero de referncias para o objeto real.
Carregamento de um objeto persistente na memria no primeiro
momento em que ele acessado.
Verificao do bloqueio (locking) do objeto real antes do acesso
para garantir que nenhum outro objeto o acessar
simultaneamente.
Estrutura


Participantes
Proxy (ImageProxy):
o Mantm uma referncia que permite o acesso ao objeto real. Pode se
referir a Subjects e as interfaces Subject e RealSubject so as mesmas.
o Disponibiliza uma interface idntica do Subject, de modo que seja um
substituto do objeto real.
o Controla o acesso ao objeto real e pode ser responsvel pela sua criao e
remoo.
o Outras responsabilidades dependem do tipo do proxy:
Remote Proxies: responsveis pela codificao da requisio e
seus argumentos e pelo envio destes para o subject real, que
reside em um espao de endereamento diferente.
Virtual Proxies: pode realizar caching de informaes adicionais
sobre o subject real de modo a adiar o acesso a ele.
Protection Proxies: verifica se o componente que realiza a
invocao possui as permisses de acesso requeridas.
Subject (Graphics):
o Define uma interface comum para RealSubject e Proxy, de modo que um
Proxy possa ser utilizado naqueles lugares onde um RealSubject era
esperado.
RealSubject (Image): Define o objeto real que representado pelo Proxy.
Consequncias
O Proxy introduz um nvel a mais de indireo, com objetivos diversos:
o O Remote Proxyesconde o fato que objetos residem em um espao de
endereamento diferente
o O Virtual Proxy pode realizar otimizaes tais como criar o objeto sob
demanda.
o Tanto o Protection Proxy quando o Smart Reference permitem a
realizao de tarefas de limpeza do ambiente quando o objeto acessado.
Outra otimizao importante: copy-on-write pode reduzir significativamente o
custo computacional da cpia de objetos muito pesados.
Implementao
O padro Proxy pode explorar as seguintes caractersticas de linguagem:
Sobrecarregando o operator de acesso a membros em C++:
o Permite a utilizao do proxy exatamente como um ponteiro.
Exemplo prtico 12
public interface PotOfTeaInterface {
public void pourTea();
}
PotOfTeaInterface.java

public class PotOfTeaProxy implements PotOfTeaInterface {
PotOfTea potOfTea;
public PotOfTeaProxy() {}
public void pourTea() {
potOfTea =new PotOfTea();
potOfTea.pourTea();
}
}
PotOfTeaProxy.java
public class PotOfTea implements PotOfTeaInterface {
public PotOfTea() {
System.out.println("Fazendo uma Xicara de Ch");
}
public void pourTea() {
System.out.println("Ch puro");
}
}
PotOfTea.java
class TestProxy {
System.out.println("TestProxy: instantiating PotOfTeaProxy");
PotOfTeaInterface potOfTea =new PotOfTeaProxy();
System.out.println(" ");
System.out.println("TestProxy: pouring tea");
potOfTea.pourTea();
}
}
TestProxy.java

Exerccio
1. Identifique o padro Proxy na API de RMI de J ava.


2.3 PADRES COMPORTAMENTAIS
Os padres comportamentais atuam sobre como responsabilidades so atribudas s
entidades, ou seja, qual o comportamento das entidades. Estes padres facilitam a
comunicao entre os objetos, distribuindo as responsabilidades e definindo a
comunicao interna.
Padres com escopo de classe utilizam herana para realizar a distribuio do
comportamento. Um bom exemplo o padro Template Method, que fornece um
algoritmo (comportamento) padro e deixa as subclasses definirem alguns pontos da
execuo do algoritmo. J os padres de objetos vo compor os objetos para definir a
comunicao, como o padro Mediator, que define um objeto que realiza a comunicao
muitos-para-muitos.
Padres comportamentais referem-se a algoritmos e comunicaes entre objetos.
Os padres comportamentais abordam questes como, quais comportamentos aplicam-
se a qual estado do objeto e qual algoritmo aplicam-se a um determinado objeto em um
dado contexto. O padro comportamental Estado (State) seria uma boa adio a
qualquer estrutura se houver mudana de comportamento do objeto com base no seu
estado. Os consumidores acessam o objeto por meio de uma fachada sem estado, e a
aplicabilidade de um mtodo exposto pela interface deve ser determinada no tempo de
execuo. O padro comportamental Estratgia (Strategy) seria uma boa adio a
qualquer estrutura se o objeto desejar expor uma interface esttica e determinar qual
algoritmo executar, com base em um critrio definido no tempo de execuo.
2.3.1 Padro Chain of Responsability
Propsito
Evita acoplar o remetente de uma requisio ao seu destinatrio ao dar a mais de
um objeto a chance de servir a requisio. Compe os objetos em cascata e passa a
requisio pela corrente at que um objeto a sirva.
Motivao
Help sensvel ao contexto em aplicaes grficas;
A mensagem de help depende da parte da interface que foi clicada e do seu
contexto;
Se no existir mensagem de help para um boto, por exemplo, exibe-se a
mensagem de help genrica do dialog que o contm;
O objeto que efetivamente apresenta o help no explicitamente conhecido pelo
objeto que solicitou ajuda;
O cliente que fez a requisio no tem referncia direta ao objeto que a
processou.
Para garantir que os receptores sejam implcitos todos os objetos da cadeia
compartilham uma mesma interface.


Aplicabilidade
Utilize Chain of Responsability 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;
Quer-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.
Estrutura

Participantes
Handler. Define uma interface para tratar solicitaes. (Opcional) Implementa o
elo (link) ao sucessor.
ConcreteHandler. Trata de solicitaes pelas quais responsvel. Pode acessar
seu sucessor. Se o ConcreteHandler pode tratar a solicitao, ele assim o faz,
caso contrrio, ele repassa a solicitao para seu sucessor.

Client. Inicia a solicitao para um objeto ConcreteHander da cadeia.
Consequncias
Reduz o acoplamento:
o Um objeto no precisa conhecer qual outro objeto atende a
requisio;
o O emissor e o receptor no se conhecem explicitamente;
o Um objeto na cadeia no possui conhecimento da estrutural atual da
cadeia;
o Simplifica as interconexes entre objetos. Ao invs de manter
referncias para todos os receptores candidatos mantm-se uma nica
referncia para o seu sucessor.
Maior flexibilidade na atribuio de responsabilidades a objetos:
o Pode-se adicionar ou modificar as responsabilidades de atendimento
de uma requisio atravs de modificaes na cadeia em runtime;
o Pode-se utilizar subclassing para especializar os handlers
estaticamente;
O recebimento no garantido:
o A requisio pode ser repassada at o fim da cadeia sem receber
nenhum tratamento especfico;
o A requisio pode tambm no ser tratada se a cadeia estiver
configurada de forma inapropriada;
Implementao
Implementando a cadeia de sucessores:
o Definir novos linksou utilizar aqueles possivelmente existentes?
o Referncias ao parentem estruturas parte-todo, como em uma estrutura
de widgets, possivelmente j implementam a cadeia de alguma forma
(Composite);
Conectando os sucessores:
o Se no existem referncias pr-definidas o Handler define a interface
para requisies e armazena a referncia para o sucessor;
o Pode-se, neste caso, ter uma implementao default;
Conexo entre os sucessores.
Representando as requisies:
1. Operao hard-coded: conveniente e seguro;
2. Request Codecomo parmetro da funo handler: parmetros devem ser
empacotados e desempacotados manualmente inseguro
3. Objetos request que encapsulam os parmetros: classe Request e
derivados

Exemplo prtico 13


public class Moeda {
// Atributos
private Double espessura;
private Double raio;
private Double peso;
// Construtor
public Moeda( Double e, Double r, Double p ){
this.espessura =e;
this.raio =r;
this.peso =p;
}
// Mtodos para acessar os atributos
public Double getEspessura(){
return this.espessura;
}
public Double getPeso(){
return this.peso;
}
public Double getRaio(){
return this.raio;
}
}
Moeda.java
public abstract class Alimentador {
private Alimentador sucessor;
public abstract Double processaRequisicao( Moeda moeda );
public void setSucessor( Alimentador sucessor ){
this.sucessor =sucessor;
}
public Alimentador getSucessor(){
return this.sucessor;
}}
Alimentador.java
public class AlimentadorCinquenta extends Alimentador {
public Double processaRequisicao( Moeda moeda ){
if( moeda.getEspessura() ==2.30 ){
return( 0.50 );
}else{
return this.getSucessor().processaRequisicao( moeda );
}}
public AlimentadorCinquenta(){
}}
AlimentadorCinquenta.java
public class AlimentadorUmReal extends Alimentador {

if( moeda.getEspessura() ==2.7 ){
return( 1.00 );
}else{
return this.getSucessor().processaRequisicao( moeda );
}}
public AlimentadorUmReal(){
}}
AlimentadorUmReal.java
public class AlimentadorDesconhecido extends Alimentador {
return( 0.00 );
}
public AlimentadorDesconhecido(){
}}
AlimentadorDesconhecido.java
public class ClienteChain {
public static void main( String args[] ){
// Declarao dos alimentadores.
AlimentadorCinquenta ali_cinquenta =new
AlimentadorCinquenta();
AlimentadorUmReal ali_umReal =new
AlimentadorUmReal();
AlimentadorDesconhecido ali_tazzo =new
AlimentadorDesconhecido();
// Configurao das sucesses.
ali_cinquenta.setSucessor( ali_umReal );
ali_umReal.setSucessor( ali_tazzo );
// Definio das moedas.
Moeda moeda1 =new Moeda( 2.30, 0.30, 0.10 ); // R$ 0.50
Moeda moeda2 =new Moeda( 2.70, 0.15, 0.10 ); // R$ 1.00
Moeda moeda3 =new Moeda( 3.00, 0.20, 0.20 ); // R$ #.##
// Identificao das moedas.
DecimalFormat d =new DecimalFormat( "0.00" ); // forar duas
casas decimais.
System.out.println( "Primeira Moeda: $" +
d.format( ali_cinquenta.processaRequisicao(moeda1) ) );
System.out.println( "Segunda Moeda: $" +
System.out.println( "Terceira Moeda: $" +
}}
ClienteChain.java

Exerccio
1. Escreva uma aplicao em J ava que receba um texto ou arquivo de texto da linha
de comando:
a. O texto deve ser lido e estatsticas devem ser impressas sobre: a) o
nmero de espaos encontrados, b) o nmero de letras 'a' e c) o nmero
de pontos.
b. Use Chain of Responsibility e faa com que cada tipo de caractere seja
tratado por um elo diferente da corrente.

2.3.2 Padro Command
Propsito

Encapsular uma requisio como um objeto, permitindo que clientes
parametrizem diferentes requisies, filas ou requisies de log, e suportar operaes
reversveis.
Motivao
Necessidade de emisso de requisies a objetos sem conhecer nada a respeito
da operao sendo requerida;
Exemplo: botes e menus em um toolkit grfico;
Soluo: transformar a prpria requisio em um objeto;
Subclasses concretas de Command armazenam o receptor da requisio e
invocam operaes neste receptor;
PasteCommand. OpenCommand. MacroCommand;

Aplicabilidade
Deseja-se parametrizar objetos com uma ao a ser realizada:
o O Command o substituto orientado a objetos para os call-backs
procedurais;
Para especificar, enfileirar e executar requisies em momentos diferentes:
o O lifetime dos objetos Command independente da requisio original;
o Se o receptor puder ser representado de uma forma independente de
espao de endereamento, o Command pode ser transferido para ser
executado em um diferente processo ou host;
Deseja-se suporte a undo:
o A operao execute() do Command pode armazenar estado necessrio
para reverter os efeitos do comando;
o A interface do Command estendida com uma operao unexecute();
o Commands j executados so armazenados em uma lista de histrico;
o Undo e redo ilimitado atravs da navegao para trs e para frente no
histrico, executando as operaes unexecute() e execute(),
respectivamente;
Deseja-se estruturar o sistema com operaes de alto nvel baseadas em
operaes primitivas transaes;

Estrutura


Participantes
Command:
o Declara a interface para execuo da operao;
ConcreteCommand:
o Define a ligao entre o objeto receptor e a ao;
o Implementa execute()atravs de invocaes no receptor;
Client:
o Cria um objeto ConcreteCommand e ajusta seu receptor
Invoker:
o Solicita ao Command a execuo da requisio
Receiver:
o Sabe como realizar as operaes necessrias ao atendimento da
requisio;
o Qualquer classe pode funcionar como um Receiver;
Consequncias
Desacopla o objeto que invoca a operao daquele que sabe como realiz-la;
Commands so objetos de primeira-classe, podem ser manipulados e derivados
como qualquer outro objeto;
Podem-se combinar comandos em um Composite Command
Pode-se facilmente adicionar novos comandos sem modificar as classes j
existentes;
Implementao
Quo inteligente um Command deve ser?
o Simples: realiza somente a ligao entre a ao e o receptor e armazena
as operaes a serem realizadas;
o Intermedirio: descoberta dinmica do receptor;
o Complexos: implementa tudo o que for necessrio sem recorrer a um
receptor;
Suportando undo e redo:
o Pode ser necessrio armazenar estado adicional, por exemplo:
O objeto Receiver;

Os argumentos da operao realizada pelo Receiver
Quaisquer valores do Receiver modificados pela requisio;
o Um nvel x vrios nveis (ambos podem requerer cpia do Command);

Exemplo prtico 14

public interface Command{
void execute();
}
Command.java
public class TurnOnLightCommand implements Command{
private Light theLight;
public TurnOnLightCommand(Light light){
this.theLight=light;
}
public void execute(){
theLight.turnOn();
}
}
TurnOnLightCommand.java
public class TurnOffLightCommand implements Command{
private Light theLight;
public TurnOffLightCommand(Light light){
this.theLight=light;
}
public void execute(){
theLight.turnOff();
}
}
TurnOffLightCommand.java
public class Light{
public Light(){ }
public void turnOn(){
System.out.println("A luz esta ligada ");
}
public void turnOff(){
System.out.println("A luz esta desligada ");
}
}
Light.java
public class Switch {
private Command flipUpCommand;
private Command flipDownCommand;
public Switch(Command flipUpCmd,Command flipDownCmd){
this.flipUpCommand=flipUpCmd;
this.flipDownCommand=flipDownCmd;
}
public void flipUp(){
flipUpCommand.execute();
}
public void flipDown(){

flipDownCommand.execute();
}
}
Switch.java
public class ClientCommand{
Light l =new Light();
Command switchUp =new TurnOnLightCommand(l);
Command switchDown =new TurnOffLightCommand(l);
Switch s =new Switch(switchUp,switchDown);
s.flipUp();
s.flipDown();
}
}
ClientCommand.java

Exerccios
1. Implemente um pequeno banco de dados de pessoas operado por linha de
comando
Sintaxe: java Servidor <comando>[<args>]
Comandos: new <id><nome>, delete <id>, all, get <id>
Classe Pessoa: id: int, nome: String. Use um HashMap para implementar
o banco de pessoas, e outro para guardar os comandos.
2. Qual a diferena entre
Strategy e Command?
State e Command?
State e Strategy?

2.3.3 Padro Interpreter
Propsito
Dada uma linguagem, definir uma representao para sua gramtica junto com
um interpretador que usa a representao para interpretar sentenas na linguagem.
Motivao
Pode ser interessante representar instncias de um problema como sentenas
escritas em uma linguagem simples;
Utiliza-se ento um interpretador que resolve o problema interpretando estas
sentenas;
Ex: busca por padres em strings;
Ex: gramtica para definio de expresses regulares;
Aplicabilidade
Quando a gramtica for simples. Para gramticas complexas uma melhor
alternativa utilizar os geradores automticos de parsers;

Quando eficincia no for um problema crtico. Os interpretadores mais
eficientes no utilizam rvores sintticas diretamente e sim outras estruturas, tais
como autmatos;
Estrutura

Participantes
AbstractExpression(RegularExpression):
o Declara a operao abstrata interpret()comum a todos os ns da rvore
sinttica abstrata;
TerminalExpression(LiteralExpression):
o Implementa a operao interpret() associada a smbolos terminais da
gramtica;
o Uma instncia desta classe requerida para cada smbolo terminal da
sentena;
NonTerminalExpression(AlternationExpression, etc):
o Uma instncia desta classe requerida para cada regra de produo R::=
R1, R2, R3, ..., Rn da gramtica;
o Mantm atributos do tipo AbstractExpression para cada um dos smbolos
R1, R2, ...,Rn;
o Implementa a operao interpret() para smbolos no-terminais da
gramtica, geralmente invocando a prpria operao interpret() nos
atributos R1,R2,R3,..., Rn.
Context:
o Contm informaes globais do interpretador;
Client:
o Constri (ou obtm) uma rvore sinttica abstrata representando uma
sentena particular na linguagem definida pela gramtica;
o Invoca a operao interpret();
Consequncias
fcil modificar e estender a gramtica:
o Pode-se utilizar herana para isso

o Novas expresses podem ser definidas como variaes das antigas;
Implementar a gramtica fcil:
o As classes que representam os ns da rvore tm implementao similar
e podem ser automaticamente geradas por ferramentas apropriadas;
Gramticas complexas so difceis de manter:
o Outros padres podem ser utilizados para minimizar este problema;
o Mesmo assim, para gramticas com muitas regras os geradores de
parsers representam uma melhor soluo;
Adicionando novas formas de interpretao:
o Pode-se criar novas operaes, por exemplo para suportar type-checking;
o Se muitas formas de interpretao forem necessrias, o padro Visitor
pode ser til;
Implementao
Criando a rvore sinttica abstrata:
o O padro Interpreter no define como a rvore criada, ou seja, no
resolve o problema de parsing;
o Opes: parser dirigido por tabelas, descendente recursivo, etc.;
Definindo a operao interpret():
o A operao interpret() no precisa necessariamente estar nas classes de
expresso, pode-se utilizar o Visitor;
Compartilhando smbolos terminais com o Flyweight:
o Motivado pela ocorrncia constante dos mesmos terminais;
Exemplo prtico 15

Gramtica:
o Expressao =variavel | (expressao )|somar | subtrair
o Somar =expressao +variavel

o Subtrair =expressao -variavel
o variavel =A |B |..... | Z |a |.... | z
Para a expresso:
o ((x-y) +z) a)
o Com x =5, y =2, z =3 e a =4
public abstract class ExpAlgebraica {
public abstract int interpret(Contexto ctx);
}
ExpAlgebraica.java
public class Contexto {
private Map terminalExpressions =new HashMap();
public int lookup(String nome){
return ((Integer)terminalExpressions.get(nome)).intValue();
}
public void assign(Variavel exp, int val){
terminalExpressions.put(exp.getNome(),new Integer(val));
}
}
Contexto.java
public class Variavel extends ExpAlgebraica{
private String nome;

public Variavel(String nome){
this.nome =nome;
}
public int interpret(Contexto ctx){
return ctx.lookup(nome);
}
public String getNome(){
return nome;
}
}
Variavel.java
public class Subtrair extends ExpAlgebraica{
ExpAlgebraica operando1, operando2;

public Subtrair(ExpAlgebraica exp1,ExpAlgebraica exp2){
this.operando1 =exp1;
}
@Override
return operando1.interpret(ctx) - operando2.interpret(ctx);
}
}
Subtrair.java
public class Somar extends ExpAlgebraica{
ExpAlgebraica operando1, operando2;

public Somar(ExpAlgebraica exp1,ExpAlgebraica exp2){
}
@Override
return operando1.interpret(ctx) +operando2.interpret(ctx);
}
}
Somar .java
public class ClienteInterpreter {
ExpAlgebraica x =new Variavel("X");
ExpAlgebraica y =new Variavel("Y");
ExpAlgebraica z =new Variavel("Z");
ExpAlgebraica a =new Variavel("A");

ExpAlgebraica expressao =new Subtrair(new Somar(new Subtrair(x,y),z),a);

Contexto contexto =new Contexto();

contexto.assign((Variavel)x, 5);
contexto.assign((Variavel)y, 2);
contexto.assign((Variavel)z, 3);
contexto.assign((Variavel)a, 4);

int result =expressao.interpret(contexto);
System.out.println("Resultado ="+result);
}
}
ClienteInterpreter.java

Exerccio
1. Usando objetos Command e Term como argumentos, escreva um
WhileCommand (Ver figura abaixo do pacote oozinoz )
Use como exemplo o IfCommand e considere o diagrama UML de Term
(que s possui mtodo eval());
Escreva uma aplicao que use o IfCommand e o WhileCommand
juntos;
2. Voc v alguma diferena entre os padres Command e Interpreter?

2.3.4 Padro Iterator
Proposito
Disponibilizar uma forma de acesso sequencial aos elementos de um agregado
sem expor a sua representao subjacente.
Motivao

Deve-se poder percorrer uma lista encadeada, por exemplo, sem conhecer sua
estrutura interna;
Podem existir diferentes formas de varredura e no se deseja que todo este
cdigo esteja na classe da lista;
Podem existir diferentes varreduras simultneas;
O Iterator define a interface de acesso aos elementos da lista e armazena o
elemento atual;
Pode-se definir iterators para diferentes polticas de varredura sem enumer-los
na classe List. Ex: FilteringListIterator
A dependncia explcita com o tipo do agregado (List) pode ser removida com o
uso de iterators polimrficos;
Utiliza-se um Factory Method no agregado para que o cliente no instancie um
iterator especfico;
Aplicabilidade
Para acessar o contedo de um agregado sem expor a sua representao interna;
Para suportar mltiplas varreduras em objetos agregados;
Para disponibilizar uma interface uniforme para varredura de objetos agregados
(iterao polimrfica);
Estrutura

Participantes
Iterator:
o Define a interface para acessar e percorrer elementos;
ConcreteIterator:
o Implementa a interface do Iterator;
o Mantm a posio atual da varredura do agregado;
Aggregate:
o Define a interface de criao do Iterator;
ConcreteAggregate:

o Implementa a interface de criao do Iterator, retornando uma instncia
de ConcreteIterator apropriada;

Consequncias
Suporta variaes na varredura do agregado:
o Diferentes formas de varredura de rvores: em ordem, pr-ordem;
o Para mudar a poltica de varredura simplesmente utiliza-se outro tipo de
Iterator;
o Subclasses do Iterator podem ser facilmente criadas com o objetivo de
suportar novas formas de varredura;
Simplificam a interface do agregado:
o A interface de varredura do Iteratorelimina a necessidade de uma
interface similar na classe do agregado;
Suportam diferentes varreduras simultneas:
o Cada Iterator possui seu prprio estado;
Implementao
Quem controla a iterao?
o Iterator externo: o cliente controla a varredura (mais flexveis);
o Iterator interno: o cliente solicita que o iterator execute uma determinada
operao e esta por ele aplicada a todos os elementos do agregado
(menos flexveis, porm mais fceis de utilizar);
o Implementar um operator=() entre agregados difcil com um iterator
interno;
Quem define o algoritmo de varredura?
o O prprio iterator:
Podem-se utilizar diferentes algoritmos de iterao no mesmo
agregado;
Pode-se reutilizar o mesmo algoritmo em outros agregados;
Por outro lado, o iterator pode precisar acessar dados privados do
agregado, violando o encapsulamento (friend);
o O agregado, recebendo o iterator como parmetro:
Neste caso o iterator chamado de cursor e responsvel
somente pela referncia ao item atual da varredura;
Quo robusto o iterator?
o Se elementos so adicionados ou removidos durante a varredura, pode-se
deixar de percorrer elementos ou acess-los duas vezes;
o Uma soluo fcil, porm custosa, realizar a varredura em uma cpia
do agregado;
o Um robust iterator garante que inseres e remoes no iro interferir
na varredura, mesmo sem realizar cpia do agregado:

Pode-se, por exemplo, registrar os iterators nos agregados. Eles
seriam notificados, e reorganizados, sempre que acontecesse uma
modificao no agregado;
Operaes adicionais no Iterator:
o As operaes bsicas so: first(), next(), isDone() e currentItem();
o Pode-se adicionar, entretanto previous() e skipTo();
Usando Iteratorspolimrficos em C++:
o Iterators polimrficos adicionam um custo, pois so alocados
dinamicamente por um Factory Method;
o O cliente responsvel pela sua desalocao, o que pode ser difcil se
existem mltiplos pontos de sada e tratamento de exceptions;
o Entretanto, pode-se utilizar um Proxy (smart pointer);
o Uso de Iterator sem composites:
Iterators externos que realizam varreduras em Composites podem
ser difceis de implementar (requer pilha ou recurso);
Pode ser mais fcil definir um iterator interno ou, se a estrutura
interna do composite permitir, utilizar uma abordagem baseada
em cursor;
o Iterators null:
Iterator degenerado, til para tratar condies de contorno;
Um iterator null aquele cuja varredura est sempre concluda
(isDone() sempre igual a true);
Permitem que varreduras em rvores sejam implementadas de
maneira uniforme (folhas retornam iterators null para percorrer os
filhos no existentes);
Exemplo prtico 16
public class BitSetIterator implements Iterator<Boolean>{
private final BitSet bitset;
private int index;
public BitSetIterator(BitSet bitset) {
this.bitset =bitset;
}
public boolean hasNext() {
return index <bitset.length();
}
public Boolean next() {
if (index >=bitset.length()) {
throw new NoSuchElementException();
}
boolean b =bitset.get(index++);
return new Boolean(b);
}
public void remove() {
throw new UnsupportedOperationException();
}
}
BitSetIterator.java
public class ClientBitSet {
// create BitSet and set some bits
BitSet bitset =new BitSet();
bitset.set(1);
bitset.set(19);

bitset.set(20);
bitset.set(47);
BitSetIterator iter =new BitSetIterator(bitset);
while (iter.hasNext()) {
Boolean b =iter.next();
String tf =(b.booleanValue() ? "T" : "F");
System.out.print(tf);
}
System.out.println();
}
}
ClientBitSet.java

Exerccio
Escreva um type-safe iterator para objetos da hierarquia de Figuras (Circulos,
Retangulos, etc.): objetos retornados pelo iterator devem ser do tipo Figura.
o Implemente o Iterator na ListaDeFiguras (use internamente o
List.iterator);
o Use um mtodo iterator() e esconda a implementaao em uma classe
interna
o Use next() e hasNext() para navegar
Quantos iterators voc conhece nas APIs da linguagem J ava (alm de
java.util.Iterator)?
2.3.5 Padro Mediator
Propsito
Define um objeto que encapsula o modo como um conjunto de objetos interage.
Promove um acoplamento fraco entre objetos, evitando que referenciem diretamente um
ao outro e permitindo que se possa variar a interao entre eles de modo independente.
Motivao
Promover acoplamento fraco no permitindo que os objetos se referenciem;
Em um sistema de informao, um Mediator pode ser utilizado para manter a
consistncia da interface;
Ex.: habilitar ou desabilitar opes em funo da seleo de outras opes. Por
exemplo, considere a implementao de caixas de dilogo em uma interface
grfica de usurio. Uma caixa de dialogo usa uma janela para apresentar uma
coleo de widgets, tais como botes, menus e campos de entrada.
Aplicabilidade
Utilize o padro Mediator quando:
Um conjunto de objetos se comunica de uma forma bem definida, porm
complexa. As interdependncias resultantes no so estruturadas e so de difcil
compreenso;

O reuso de objetos difcil uma vez que um objeto se refere e se comunica com
muitos outros objetos;
Um comportamento que distribudo entre vrias classes deve ser customizado
sem o uso excessivo de subclasses;
Estrutura

Uma estrutura de objeto tpica pode se assemelhar seguinte:

Participantes
Mediator:
o Define uma interface para comunicao com os objetos Colleague
ConcreteMediator:
o Implementa comportamento cooperativo atravs da coordenao de
objetos Colleague;
o Conhece e mantm seus objetos Colleagues;
Colleague classes:
o Cada classe Colleague conhece seu objeto Mediator de outra forma;
o Cada objeto Colleague comunica-se com o seu objeto Mediator em
situaes nas quais teria de comunicar-se com outro objeto Colleague;
Consequncias
Limita hierarquia de subclasses apenas classe Mediator;
Promove desacoplamento entre Colleagues;

Simplifica protocolos entre objetos: muitos-para-muitos substitudos com um-
para-muitos;
Abstrai como os objetos cooperam (ajuda a entender o funcionamento dos
objetos);
Centraliza o controle (objeto monoltico).
Implementao
Omisso da classe Mediator abstrata:
o Quando Colleagues interagem com um nico Mediator;
Comunicao Colleague-Mediator:
o Colleagues se comunicam com Mediator quando ocorre um evento de
interesse. (ver padro Observer, como uma opo);
Exemplo prtico 17

public class ButtonView extends JButton implements Command {
Mediator mediator;
public ButtonView(ActionListener listener, Mediator mediator){
super("View");
addActionListener(listener);
this.mediator =mediator;
mediator.registerView(this);
}
public void execute() {
mediator.view();
}
}
ButtonView.java
public class ButtonSearch extends JButton implements Command {
Mediator mediator;
ButtonSearch(ActionListener listener, Mediator mediator{
super("Search");
addActionListener(listener);
this.mediator =mediator;
mediator.registerSearch(this);
}
public void execute() {
mediator.search();
}
}

ButtonSearch.java
public interface Command {
public void execute();
}
Command.java
public class Mediator {
ButtonView buttonView;
ButtonBook buttonBook;
ButtonSearch buttonSearch;
LabelDisplay labelDisplay;
public void registerView(ButtonView buttonView) {
this.buttonView =buttonView;}
public void registerBook(ButtonBook buttonBook) {
this.buttonBook =buttonBook;}
public void registerSearch(ButtonSearch buttonSearch) {
this.buttonSearch =buttonSearch;
}
public void registerDisplay(LabelDisplay labelDisplay) {
this.labelDisplay =labelDisplay;
}
public void view() {
buttonView.setEnabled(false);
buttonBook.setEnabled(true);
buttonSearch.setEnabled(true);
labelDisplay.setText("Viewing...");
}
public void book() {
buttonBook.setEnabled(false);
buttonView.setEnabled(true);
buttonSearch.setEnabled(true);
labelDisplay.setText("Booking...");
}
public void search() {
buttonSearch.setEnabled(false);
buttonBook.setEnabled(true);
buttonView.setEnabled(true);
labelDisplay.setText("Searching...");
}
}
Mediator.java
class MediatorExample extends JFrame implements ActionListener {
Mediator mediator =new Mediator();
public MediatorExample() {
JPanel p =new JPanel();
p.add(new ButtonView(this, mediator));
p.add(new ButtonBook(this, mediator));
p.add(new ButtonSearch(this, mediator));
getContentPane().add(new LabelDisplay(mediator),
BorderLayout.NORTH);
getContentPane().add(p, BorderLayout.SOUTH);
setTitle("Mediator Example");
setSize(300, 200);
addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) {
System.exit(0);
}
});
setVisible(true);
}
public void actionPerformed(ActionEvent e) {
if (e.getSource() instanceof Command) {
Command c =(Command)e.getSource();
c.execute();
}
}
new MediatorExample();
}
}
MediatorExample.java


Exerccios
1. Implemente o cdigo que falta nas classes fornecidas para fazer o mediador
funcionar;
2. Introduza um mediador para eliminar a dependncia entre as classes abaixo;
Faa com que cada objeto s conhea o mediador;
Implemente um mecanismo que permita que novos objetos possam se
cadastrar no mediador;
2.3.6 Padro Memento
Propsito
Externalizar o estado interno de um objeto para que o objeto possa ter esse
estado restaurado posteriormente, isto , Capturar e externalizar o estado interno de um
objeto sem quebrar o encapsulamento.
Motivao
Algumas vezes necessrio registrar o estado interno de um objeto. Isso
necessrio na implementao de mecanismos de checkpoints e de desfazer (operaes)
que permitem aos usurios retroceder de operaes-tentativas ou recuperar-se de erros.
Permitir a implementao de mecanismos de checkpoint em um sistema para
possibilitar undo;
til em situaes que o padro Command no funciona;
Em um processamento numrico longo, podem ser salvos estados
intermedirios;
Aplicabilidade
Use o padro Memento quando:
Quando um snapshot do (parte do) estado de um objeto precisa ser armazena da
para que ele possa ser restaurado ao seu estado original posteriormente;
Quando uma interface direta para se obter esse estado iria expor detalhes de
implementao e quebrar o encapsulamento do objeto;
Estrutura


Participantes
Memento:
o Armazena o estado interno do objeto Originator;
o Protege o encapsulamento do estado, no permitindo que outros objetos
alm do Originator tenham acesso;
Originator:
o Cria um memento contendo um instantneo do seu estado interno
corrente;
o Usa o memento para restaurar o seu estado interno;
Caretaker:
o responsvel pela custdia do memento;
o Nunca opera ou examina os contedos de um memento;
Consequncias
Vantagens:
o Preservao das fronteiras de encapsulamento, isto , o estado do
Originator guardado fora dele sem a perda do encapsulamento;
o O Originator simplificado por no ter a responsabilidade de
gerenciamento de estados anteriores;
Desvantagens:
o O uso de mementos pode ser uma soluo cara, dependendo do tamanho
e do nmero de estados a serem salvos;
o O Caretaker ganha a responsabilidade de deleo dos mementos
armazenados;
o Em determinadas linguagens pode ser difcil garantir que apenas o
Originator ser capaz de acessar o memento. (Ex: Em C++pode-se fazer
um cast para void *. Em J ava pode-se fazer um cast para Object);
Implementao
Aspectos a serem considerados ao implementar o padro Memento:
1. Suporte de Linguagem.
2. Armazenando mudanas incrementais.
Exemplo prtico 18
public class Originator {
private String state;
/* lots of memory using private data that does not have to be
saved. Instead we use a small memento object. */
public void set(String state) {
System.out.println("Originator: Setting state to " +state);
this.state =state;
}
public Object saveToMemento() {
System.out.println("Originator: Saving to Memento.");
return new Memento(state);
}

public void restoreFromMemento(Object m) {
if (m instanceof Memento) {
Memento memento =(Memento) m;
state =memento.getSavedState();
System.out.println("Originator: State after restoring
from Memento: " +state);
}
}
}
Originator.java
public class Caretaker {
private List<Object>savedStates =new ArrayList<Object>();
public void addMemento(Object m) {
savedStates.add(m);
}
public Object getMemento(int index) {
return savedStates.get(index);
}
}
Caretaker.java
public class Memento {
public Memento(String stateToSave) {
state =stateToSave;
}
public String getSavedState() {
return state;
}
}
Memento.java
public class MementoExample {
Caretaker caretaker =new Caretaker();
Originator originator =new Originator();
originator.set("State1");
caretaker.addMemento(originator.saveToMemento());
caretaker.addMemento(originator.saveToMemento());
originator.restoreFromMemento(caretaker.getMemento(1));
}
}
MementoExeample.java

Exerccios
1. Escreva uma aplicao grfica simples que permite digitar texto em um
TextField que copiado para um TextArea (um objeto em cada linha) quando o
usurio aperta o boto gravar. Em seguida o TextField esvaziado
a. Crie um boto "Desfazer"
b. Implemente uma operao de Undo que permita desfazer todas as
operaes (recuperar o texto anterior no TextField e mostrar o TextArea
sem o texto)
2. Grave as alteraes em disco de forma que, se a aplicao fechar, quando ela
reiniciar, ela lembre do estado em que estava antes de fechar.


2.3.7 Padro Observer
Propsito
Definir uma dependncia um-para-muitos entre objetos para que quando um
objeto mudar de estado, todos os seus dependentes sejam notificados e atualizados
automaticamente.
Motivao
A mesma informao (modelo) pode ser exibida em diferentes formatos (viso)
em paralelo;
Suponhamos que dados estatsticos devem ser exibidos, ao mesmo tempo, em
forma de tabela e grfico;
Esses dados podem ser alterados durante a exibio;
O padro Observer descreve uma forma de manuteno destes relacionamentos
de modo que observadores e repositrios sejam facilmente substitudos;
Aplicabilidade
Use o padro observer em qualquer uma das seguintes situaes:
Quando uma abstrao tem dois aspectos, um dependente do outro;
Quando uma mudana num objeto exige mudanas em outros, e quando no se
sabe quantos objetos necessitam ser mudados;
Quando um objeto deveria ser capaz de notificar outros objetos sem fazer
hipteses, ou usar informaes, de quem so estes objetos.
Estrutura

Participantes
Subject:
o So objetos observveis;
o Conhece seus observadores;
Observer:

o Define uma interface para objetos que devem ser notificados de
mudanas em um Subject;
ConcreteSubject:
o Armazena estados de interesse dos objetos ConcreteObserver;
o Envia notificaes para seus Observers quando esses estados mudam;
Consequncias
fcil adicionar observadores sem modificar o observvel ou os outros
observadores;
Permite reusar Subjects sem reusar seus Observers e vice-versa;
Acoplamento fraco entre o Subject e o Observer;
o O sujeito no conhece a classe concreta dos observadores
Suporte para comunicaes em broadcast
o Mensagem de notificao enviada para todos sem especificar os que iro
receber
Atualizaes desconhecidas
o Um observador no sabe qual outro observador fez a modificao
Implementao
1. Mapeando subjects para seus observadores.
2. Observando mais que um subject.
3. Quem dispara a atualizao?
4. Referncias ao vazio para subjects deletados.
5. Garantindo que o estado do subject autoconsistente antes da emisso da
notificao.
6. Evitando protocolos de atualizao especficos dos observadores: push e pull.
7. Especificando explicitamente as modificaes de interesse.
8. Encapsulando a semntica de atualizaes complexas.
Exemplo prtico 19


public interface IObserver {
void update(String state);
}
IObserve.java
public class Observer implements IObserver {
public String getState() {
return state;
}
public void setState(String state) {
this.state =state;
}
public void update(String state) {
setState(state);
System.out.println("Observer has received update signal
with new state: " +getState());
}
}
Observer.java
public class Observer1 implements IObserver {
return state;
}
this.state =state;
}
setState(state);
System.out.println("Observer1 has received update signal
}
}
Observer1.java
public class Observer2 implements IObserver {
return state;
}
this.state =state;
}
setState(state);
System.out.println("Observer2 has received update signal
}
}
Observer2.java
public class LogSubject {
private List<IObserver>observerList =new
ArrayList<IObserver>();
return state;}
public void attach(IObserver observer) {
observerList.add(observer);
}
public void detach(IObserver observer) {
observerList.remove(observer);
}
this.state =state;
stateChanged();
}
private void stateChanged() {
for (IObserver item: observerList) {
item.update(getState());
}}
}
LogSubject.java

public class Client {
LogSubject subject =new LogSubject();
IObserver ob =new Observer();
IObserver ob1 =new Observer1();
IObserver ob2 =new Observer2();
subject.attach(ob);
subject.attach(ob1);
subject.attach(ob2);
subject.setState("state1");
subject.detach(ob1);
}
}
Client.java

Exerccio
1. Veja a implementao do padro observer nos componentes do pacote AWT;
2. Destaque as diferenas entre o padro original e a implementao do AWT;
2.3.8 Padro State
Propsito
Permite que um objeto altere seu comportamento quando mudar seu estado, isto
, permitir que um objeto modifique o seu comportamento em funo do seu estado
interno. O objeto ir aparentar mudar de classe.
Motivao
Gerar o efeito de uma troca de tipo de um objeto em tempo de execuo;
Um forno de micro-ondas deve se comportar de formas diferentes em funo do
seu estado quando o boto de ligar pressionado;
Aplicabilidade
Use o padro State quando:
O comportamento de um objeto depender do seu estado e ele tiver que mudar de
comportamento em tempo de execuo em funo de uma mudana no seu
estado;
As operaes contiverem grandes estruturas condicionais, com muitas
alternativas. Frequentemente, tais estruturas iro conter grandes pores de
cdigo que iro se repetir atravs de vrias operaes, gerando replicao
desnecessria de cdigo. O padro State coloca cada ramo da estrutura
condicional em uma classe separada, permitindo, assim, tratar os estados como
se fossem objetos e tornar mais simples a implementao de uma mquina de
estados;
Estrutura


Participantes
Context:
o Define a interface de interesse para os clientes;
o Classe cujas instncias exibem um comportamento que deve ser
modelado por uma mquina de estados.
o As instncias desta classe determinam os seus respectivos estados
correntes atravs de uma referncia (State) para uma instncia de uma
subclasse concreta (ConcreteState) da classe State;
State:
o Define uma interface para encapsulamento associado com um
determinado estado do Context.
o Esta classe a superclasse de todas as classes usadas para representar os
estados de uma instncia da classe Context.
ConcreteState subclasses:
o Cada subclasse implementa um comportamento associado com um
estado do Context.
Consequncias
1. O padro State implementa uma mquina de estados particionando os
comportamentos relativos aos estados e organizando tais comportamentos em
objetos especficos. Desse modo, novos estados e transies podem ser
facilmente adicionados mquina de estados atravs da definio de novas
subclasses.
2. Quando um objeto define o seu estado corrente unicamente em termos dos
valores dos seus atributos, a suas transies de estado no tm representao
explcita; elas ficam caracterizadas apenas pela mudana de valores de alguns
atributos. A introduo de objetos distintos para representar os diferentes estados
de mquina de estados torna as transies mais explcitas.
Implementao
1. Definio de mudanas de estado: o padro no especifica que participante
define os critrios para mudana de estados, caso sejam fixos, isto pode ser
implementado no Contexto, caso os critrios sejam mais flexveis, prefervel
deixar a cargo das subclasses qual o sucessor e quando a mudana ocorre, no

caso, a interface deve permitir que as subclasses alterem o estado do contexto
explicitamente.
2. Os estados tambm podem ser definidos em uma tabela que mapeia cada
possvel entrada para estados sucessores, porm esta abordagem mais
complexa e menos eficiente.
3. Escolha de abordagem entre criar os objetos de estado apenas quando forem
necessrios, e destru-los depois do uso (prefervel quando estados no mudam
muito e no so conhecidos em tempo de execuo), OU cri-los de antemo e
no destru-los (estados mudam com frequncia).
4. Usa herana dinmica. A mudana de comportamento para uma determinada
solicitao poder ser obtida pela mudana da classe de objeto em tempo de
execuo, porm, isto no possvel na maioria das linguagens de programao
orientada a objetos.
Exemplo prtico 20

public interface State {
public void writeName(StateContext stateContext, String name);
}
State.java
public class StateA implements State {
public void writeName(StateContext stateContext, String name) {
System.out.println(name.toLowerCase());
stateContext.setState(new StateB());
}
}
StateA.java
public class StateB implements State {
private int count=0;
public void writeName(StateContext stateContext, String name){
System.out.println(name.toUpperCase());
if(++count>1) {
stateContext.setState(new StateA());
}
}
}
StateB.java
public class StateContext {
private State myState;
public StateContext() {
setState(new StateA());
}
public void setState(State stateName) {
this.myState =stateName;
}
public void writeName(String name) {
this.myState.writeName(this, name);
}
}
StateContext.java

public class TestClientState {
StateContext sc =new StateContext();
sc.writeName("Segunda");
sc.writeName("Tera");
sc.writeName("Quarta");
sc.writeName("Quinta");
sc.writeName("Sexta");
sc.writeName("Sabado");
}
}
TestClientState.java

Exerccio
1. Refatorar a classe Porta (representada em UML abaixo) para representar seus
estados usando o padro State:

A porta funciona com um boto que alterna os estados de aberta,
abrindo, fechada, fechando, manter aberta;
Execute a aplicao e teste seu funcionamento;
2.3.9 Padro Strategy
Propsito
Definir uma famlia de algoritmos, encapsular cada um, e faz-los
intercambiveis. Strategy permite que algoritmos mudem independentemente entre
clientes que os utilizam.
Motivao
Existem muitos algoritmos para quebrar um stream de texto em linhas.

Codificar de maneira fixa e rgida tais algoritmos nas classes que os utilizam no
desejvel, por vrias razes:
Os clientes que necessitam das quebras de linhas se tornam mais complexos
se incluem o cdigo de quebra de linhas. Isso os torna maiores e mais
difceis de manter, especialmente se suportam mltiplos algoritmos de
quebra de linhas.
Diferentes algoritmos sero apropriados em diferentes situaes. No seria
uma boa estratgia suportar mltiplos algoritmos de quebra de linha se no
for necessrio us-los.
difcil adicionar novos algoritmos e variar os existentes quando a quebra
de linha parte integrante de um cliente.
Podemos evitar estes problemas definindo classes que encapsulam diferentes algoritmos
de quebra de linhas. Um algoritmo encapsulado desta maneira chamado de strategy
(estratgia).
Aplicabilidade
Use o padro Strategy quando:
Muitas classes relacionadas diferem somente no seu comportamento. As
estratgias fornecem uma maneira de configurar uma classe com um, dentre
muitos comportamentos.
Voc necessita de variantes de um algoritmo. Por exemplo, podemos definir
algoritmos que reflitam diferentes solues de compromisso entre espao/tempo.
Um algoritmo usa dados que os clientes deveriam desconhecer. Use o padro
Strategy para evitar a exposio das estruturas de dados complexas, especficas
do algoritmo.
Estrutura

Participantes
Contex: (Client)
o configurada como um objeto ConcreteStrategy;
o Mantm uma referncia para um objeto Strategy;
o Pode definir uma interface que permite a Strategy acessar seus dados;
Strategy:

o Define uma interface comum para acessar as operaes definidas pelas
suas subclasses. Pode-se usar uma interface, ao invs de uma classe
abstrata, para exercer este papel.
ConcreteStratey:
o Definem os diferentes mtodos que implementam as diferentes
estratgias existentes para a operao solicitada pelo cliente.
Consequncias
1. Podemos usar este padro para criar diferentes hierarquias de estratgias, que
iro definir famlias de algoritmos e comportamentos relacionados.
2. Uma alternativa ao uso do padro Strategy seria especializar a classe Client
(classe context) para lhe dar diferentes comportamentos. Entretanto, isso
congelaria o comportamento do cliente, misturando a implementao do
algoritmo em questo com o resto do cdigo da classe Client (contex), e
tornando esta classe mais difcil de compreender, manter e estender. Alm disso,
teramos a desvantagem de no poder variar os algoritmos dinamicamente. A
soluo dada pelo padro Strategy permite variar o algoritmo
independentemente dos seus clientes, tornando mais fcil troc-los, compreend-
los e estend-los.
3. Uma possvel desvantagem do padro Strategy estaria no fato de que um cliente
pode ser obrigado, em algumas situaes, a conhecer a maneira pela qual as
estratgias diferem uma das outras. Isso poderia levar a uma situao
indesejvel, onde os clientes teriam que estar expostos aos detalhes de
implementao das diferentes estratgias.
Exemplo prtico 21

public interface SortInterface {
public void sort(double[] list);
}
SortInterface.java
public class QuickSort implements SortInterface {
public void sort(double[] u) {
sort(u, 0, u.length - 1);
}

private void sort(double[] a, int left, int right) {
if (right <=left) return;
int i =part(a, left, right);
sort(a, left, i-1);
sort(a, i+1, right);
}
private int part(double[] a, int left, int right) {
int i =left;
int j =right;
while (true) {
while (a[i]<a[right])
i++;
while (smaller(a[right], a[--j]))
if (j ==left) break;
if (i >=j) break;
swap(a, i, j);
}
swap(a, i, right);
return i;
}
private boolean smaller(double x, double y) {
return (x <y);
}
private void swap(double[] a, int i, int j) {
double swap =a[i]; a[i] =a[j]; a[j] =swap;
}
}
QuickSort.java
public class BubbleSort implements SortInterface {
public void sort(double[] list) {
//Bubblesort algorithm here
}
}
BubbleSort.java
public class SortingContext {
private SortInterface sorter =null;
public void sortDouble(double[] list) {
sorter.sort(list);
}
public SortInterface getSorter() {
return sorter;
}
public void setSorter(SortInterface sorter) {
this.sorter =sorter;
}
}
SortingContext.java
public class TestSortingClient {
double[] list ={1,2.4,7.9,3.2,1.2,0.2,10.2,
22.5,19.6,14,12,16,17};
SortingContext context =new SortingContext();
context.setSorter(new QuickSort());
context.sortDouble(list);
for(int i =0; i<list.length; i++) {
System.out.println(list[i]);
}
}
}
TestSortingClient.java

Exerccio
1. Escreva um programa que descubra o dia da semana e, repasse o controle para
uma estratgia especfica:

o A estratgia deve imprimir a mensagemDoDia() correspondente ao dia
da semana.
o Para descobrir o dia da semana crie um new GregorianCalendar() para
obter a data corrente e use get(Calendar.DAY_OF_WEEK) para obter o
dia da semana (de 0 a 6).
2. Qual a diferena entre Strategy e State?
2.3.10 Padro Template Method
Propsito
Definir o esqueleto de um algoritmo dentro de uma operao, deixando alguns
passos a serem preenchidos pelas subclasses. Template Method permite que suas
subclasses redefinam certos passos de um algoritmo sem mudar sua estrutura.
Motivao
Ao definir alguns dos passos de um algoritmo usando operaes abstratas, o
template method fixa a ordem desses passos, mas deixa s subclasses prover o
comportamento concreto.
Aplicabilidade
O padro Template Method pode ser usado:
Implementar a parte invariante de um algoritmo uma nica vez e deixar que as
subclasses implementem o comportamento variante;
Quando comportamento comum deve ser fatorado e localizado em uma classe
comum para evitar duplicao de cdigo;
Estrutura

Participantes
AbstractClass:
o Define operaes primitivas abstratas que as subclasses concretas
definem para implementar passos de um algoritmo.

o Implementa um mtodo template que define o esqueleto de um
algoritmo. O mtodo template invoca operaes primitivas, bem como
operaes definidas em AbstractClass.
ConcreteClass:
o Implementa as operaes primitivas para executarem os passos
especficos do algoritmo da subclasse.
Consequncias
Particularmente importantes em bibliotecas de classes;
Controle pelo princpio de hollywood: no nos chame, ns chamaremos voc;
Parar e usar uma classe abstrata de modo efetivo, o desenvolvedor deve entender
quais operaes so projetadas para serem sobrescritas.
Implementao
1. Usando controle de acesso em C++;
2. Minimizando operaes primitivas;
3. Convenes de nomenclatura. Pode ser identificado as operaes que deveriam
ser substitudas pela adio de um prefixo aos seus nomes. Por exemplo, Do-.
Exemplo prtico 22

public abstract class AbstractClass {
public final void templateMethod() {
System.out.println("AbstractClass.templateMethod() called");
primitiveOperation1();
primitiveOperation2();
}
public abstract void primitiveOperation1();
public abstract void primitiveOperation2();
}
AbstractClass.java
public class Concrete1 extends AbstractClass {

public void primitiveOperation1() {
System.out.println("Concrete1.primitiveOperation1() called");
}

}
}
Concrete1.java
public class Concrete2 extends AbstractClass {
}
}
}
Concrete2.java
public class TestTemplateMethod {
System.out.println("Test TemplateMethod");
System.out.println("-------------------------");
AbstractClass class1 =new Concrete1();
AbstractClass class2 =new Concrete2();
class1.templateMethod();
class2.templateMethod();
}
}
TestTemplateMethod.java

Exerccio
1. Escreva um Comparator para ordenar palavras pela ltima letra. Escreva uma
aplicao que use Arrays.sort() para testar a aplicao.
2. Mostre como voc poderia escrever um template method para gerar uma classe
J ava genrica (contendo nome, extends, mtodos etc.).
3. Escreva uma aplicao que gere uma classe J ava compilvel que imprima uma
mensagem na tela.
Escreva uma segunda aplicao que permita ao usurio escolher o nome
da classe e a mensagem a ser impressa.
Grave o cdigo gerado em um arquivo com o mesmo nome que a classe.
2.3.11 Padro Visitor
Propsito
Representar uma operao a ser realizada sobre os elementos de uma estrutura
de objetos. Visitor permite definir uma nova operao sem mudar as classes dos
elementos nos quais opera.
Motivao
Faa com que cada elemento aceite um objeto visitante e o chame atravs de
um mtodo apropriado. Para cada nova operao que se deseja acrescentar, cria-
se um objeto Visitante novo.
o Exemplo
Para auditar, crie um objeto da classe AuditVisitor;
Este objeto tem os mtodos visitBreaker(Breaker), e
visitLine(Line), etc.;

Cada elemento da hierarquia aceita o visitante com o mtodo accept (Visitor) e
chama o mtodo apropriado do visitante;
Em resumo: a operao a ser feita depender tanto do tipo de Visitor quanto do
tipo de elemento que o Visitor visite;
Aplicabilidade
Uma estrutura de objetos contm muitas classes de objetos com interfaces que
diferem e quando se deseja executar operaes sobre estes objetos que
dependem das suas classes concretas;
Muitas operaes distintas e no relacionadas necessitam ser executadas sobre
objetos de uma estrutura de objetos, e quando se deseja evitar a poluio das
suas classes com estas operaes;
As classes que definem a estrutura do objeto raramente mudam, porm,
frequentemente se deseja definir novas operaes sobre a estrutura.
Estrutura

Participantes
Visitor (AbstractVisitor)
o Declara uma operao de visita para cada classe de ElementoConcreto na
estrutura de objetos;
o O nome da operao identifica a classe que est chamando o Visitor (ex.
visitBreaker());
o Desta forma, o Visitor sabe a classe concreta do elemento sendo visitado
e pode acessar este objeto por sua interface;

ConcreteVisitor (AuditVisitor)
o Implementa cada operao declarada pelo Visitor. Cada operao
implementa uma fragmento do algoritmo definido para a classe
correspondente de objetos na estrutura;
o O ConcreteVisitor pode acumular estado durante a varredura da estrutura
de objetos;
Element (Element)
o Define uma operao accept() que recebe um Visitor;
ConcreteElement (Breaker)
o Implementa uma operao accept() que recebe um Visitor e chama a
operao de visita apropriada deste Visitor;
Exemplo: visitBreaker();
Object Structure
o Pode enumerar seus elementos;
o Pode prover uma interface de mais alto nvel para que o Visitor visite os
elementos;
o frequentemente um Composite, mas pode ser uma coleo simples;
Consequncias
Visitor permite adicionar novas operaes com facilidade:
o Basta adicionar um novo Visitor;
o Se a funcionalidade estivesse espalhada nas classes da estrutura, cada
classe deveria ser alterada para introduzir a nova operao;
Um Visitor rene operaes relacionadas e separa operaes no relacionadas;
o Comportamento relacionado no est espalhado (coeso), mas localizado
num Visitor;
o Comportamento no relacionado est presente em objetos Visitor
diferentes;
Adicionar novas classes ConcreteElement difcil:
o Cada ConcreteVisitor tem que ser mudado para adicionar uma operao
para visitar este tipo de elemento;
o Use Visitor se as classes da estrutura so estveis, mas operaes so
frequentemente adicionadas;
Visitas em hierarquias diferentes:
o Observe que um Visitor pode muito bem definir operaes de visitas em
elementos que no participem da mesma hierarquia;
o Isso no seria possvel se, por exemplo, um mero iterador fosse usado
para varrer a estrutura;
Acumulao de estado:
o Um Visitor pode acumular estado durante as visitas;
o Sem este objeto Visitor, o estado deveria ser acumulado num objeto
adicional passado como parmetro (padro Collecting Parameter);
Quebra de encapsulao:

o J que a operao est dentro de um Visitor, e fora de um
ConcreteElement, o ConcreteElement poder ter que expor mais
interfaces do que seria desejvel para que o Visitor possa acess-lo;
o Isso pode comprometer a encapsulao;
Implementao
Double Dispatch:
o Em linguagens comuns (C++, Smalltalk, J ava), o mtodo chamado
depende da mensagem e do objeto receptor;
o Algumas linguagens, tais como CLOS (mas no C++, Smalltalk, J ava)
oferecem Double Dispatch, em que o mtodo chamado depende da
mensagem e de dois outros objetos;
o Visitor essencialmente simula Double Dispatch, pois a operao
realizada depende do tipo do Visitor e do tipo elemento visitado;
Em vez de usar binding dinmico simples colocando a operao
na interface do Elemento, juntam-se as operaes num Visitor e
usamos accept() para realizar um nvel a mais de dispatch em
tempo de execuo;
Quem responsvel pode varrer a estrutura de objetos?
o Um Visitor deve visitar todos os elementos de uma estrutura
o Quem tem a responsabilidade de realizar a varredura da estrutura e
chamar accept() em cada elemento?
A iterao pode ser feita na estrutura de objetos
Itera-se sobre os elementos, chamando accept() para cada
um;
Num Composite, o accept() de um elemento composto
pode chamar accept() dos filhos;
Podemos usar um iterador, fora da estrutura de objetos:
Se o iterador for externo, o cliente que faz a varredura;
Se o iterador for interno, o prprio iterador que chama
accept();
o Equivalente a fazer a estrutura se responsvel pela
iterao;
o Porm, neste caso, o iterador pode chamar o
Visitor diretamente, em cujo caso no haver
double dispatch
A iterao pode ser feita no prprio Visitor, mas, neste caso, cada
Visitor vai ter que repetir o cdigo de varredura;
s vezes necessrio fazer isso se a varredura depender
do resultado das operaes realizadas pelo Visitor;
Exemplo prtico 23
interface Visitor {

void visit(Wheel wheel);
void visit(Engine engine);
void visit(Body body);
void visitCar(Car car);
void visitVehicle(Vehicle vehicle);
}
Visitor.java
class Wheel {
Wheel(String name) {
this.name =name;
}
String getName() {
return this.name;
}
public void accept(Visitor visitor) {
visitor.visit(this);
}
}
Wheel.java
class Engine {
}
}
Engine.java
class Body {
}
}
Body.java
abstract class Vehicle {
protected Engine engine =new Engine();
protected Body body =new Body();
protected Wheel[] wheels;

public Engine getEngine() {
return this.engine;
}
public Body getBody() {
return this.body;
}
public Wheel[] getWheels() {
return this.wheels;
}
visitor.visitVehicle(this);
}
}
Vehicule.java
class Car extends Vehicle {
public Car() {
super();
this.wheels =new Wheel[]{
new Wheel("front left"),
new Wheel("front right"),
new Wheel("back left"),
new Wheel("back right")
};
}
visitor.visitCar(this);
}
}
Car.java
class PrintVisitor implements Visitor {

public void visit(Wheel wheel) {
System.out.println("Visiting +wheel.getName() +" wheel");
}

public void visit(Engine engine) {
System.out.println("Visiting engine");
}
public void visit(Body body) {
System.out.println("Visiting body");
}

public void visitVehicle(Vehicle vehicle) {
System.out.println("Visiting vehicle");
}
public void visitCar(Car car) {
System.out.println("Visiting car");
car.getEngine().accept(this);
car.getBody().accept(this);
for(Wheel wheel : car.getWheels()) {
wheel.accept(this);
}
}
}
PrintVisitor.java
class DoVisitor implements Visitor {
public void visit(Wheel wheel) {
System.out.println("Steering my wheel");
}
public void visit(Engine engine) {
System.out.println("Starting my engine");
}
public void visit(Body body) {
System.out.println("Moving my body");
}
public void visitCar(Car car) {
System.out.println("Starting my car");
car.getEngine().accept(this);
car.getBody().accept(this);
for(Wheel wheel : car.getWheels()) {
wheel.accept(this);
}
}
public void visitVehicle(Vehicle vehicle) {
System.out.println("Starting my vehicle");
}
}
DoVisitor.java
public class TestVisitor{
static public void main(String[] args){
Car car =new Car();
Visitor printVisitor =new PrintVisitor();
Visitor doVisitor =new DoVisitor();
car.accept(printVisitor);
car.accept(doVisitor);
}
}
TestVisitor.java

Exerccios


3. PADRES GRASP
ESPECIALISTA NA INFORMAO
CRIADOR
ACOPLAMENTO FRACO
COESO ALTA
CONTROLADOR
POLIMORFISMO
INDIREO
INVENO PURA
VARIAES PROTEGIDAS


4. ARQUITETURA EM CAMADAS
DEFINIO
COMPOSIO

REFERNCIAS
FREEMAN, E.; FREEMAN, E. Use a cabea (head first): Padres de Projeto. Rio de
J aneiro - RJ : Alta Books, 2007.
GAMMA, E. et al. Padres de Projetos: Solues reutilizveis de software orientado a
objetos. Porto Alegre - RS: Bookman, 2000.
GUEDES, G. T. A. UML 2: Uma Abordagem Prtica. 2. ed. So Paulo: Novatec, 2011.
LARMAN, C. Utilizando UML e padres: Uma introduo anlise e ao projeto
orientado a objetos e ao desenvolvimento interativo. 3. ed. Porto Alegre - RS:
Bookman, 2007.
METSKER, S. J . Design Patterns Java Workbook. [S.l.]: Addison-Wesley, 2002.
SHALLOWAY, A.; TROTT, J . Explicando Padres de Projetos: Uma nova
perspectiva em projeto orientado a objeto. 1. ed. Porto Alegre - RS: Bookman, 2004.
ISBN 0201715945.

Apostila Padrões de Software

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Apostila Padrões de Software

Загружено:

Авторское право:

Доступные форматы

Padres de Projeto de Software 0

Вам также может понравиться