Revisaoav 1

PADRES DE PROJETO DE SOFTWARE
Aula Reviso Padres estruturais GoF
O que veremos nesta terceira aula

Reviso para AV1
PADRES ESTRUTURAIS GOF AULA RAV1
Introduo
Projetar software OO reusvel e de boa qualidade uma tarefa
difcil;
Para realizar essa tarefa a contento, projetistas experientes usam
solues de sucesso com as quais j trabalharam no passado;
Isso leva descoberta de padres de projeto;
Durante duas dcadas, a comunidade de padres vem se desenvolvendo
de acordo com essa dinmica.
O que um padro?
Maneira testada ou documentada de alcanar um objetivo qualquer;
Padres so comuns em vrias reas da engenharia;
Design Patterns, ou Padres de Projeto;

Padres para alcanar objetivos na engenharia de software usando
classes e mtodos em linguagens orientadas a objeto;
Inspirado em "A Pattern Language" de Christopher Alexander, sobre
padres de arquitetura de cidades, casas e prdios;
"Design Patterns" de Erich Gamma, John Vlissides, Ralph Jonhson e
Richard Helm, conhecidos como "The Gang of Four", ou GoF,
descreve 23 padres de projeto teis
O que um padro?
"Cada padro descreve um problema que ocorre repetidas vezes em nosso

ambiente, e ento descreve o ncleo da soluo para aquele problema, de
tal maneira que pode-se usar essa soluo milhes de vezes sem nunca
faz-la da mesma forma duas vezes"
Christopher Alexander, sobre padres em Arquitetura
O que um padro?
"Os padres de projeto so descries de objetos que se comunicam e

classes que so customizadas para resolver um problema genrico de
design em um contexto especfico"
Gamma, Helm, Vlissides & Johnson, sobre padres em software
Catlogos de padres
Um catlogo de padres um grupo de padres que esto relacionados
de uma certa forma e podem ser usados juntos ou independentemente:
Core JEE(Java Enterprise Edition);
PoEAA(PatternsofEnterprise Application Architecture);
POSA(Pattern-OrientedSoftware Architecture)
GRASP(General Responsibility Assignment Software
Patterns/Principles)
GoF(Gang ofFour)
Catlogo - GoF
Classificao dos 23 padres segundo GoF*
Padres de Criao
fornecem um guia de como instanciar objetos. Esta ao
normalmente envolve decises dinmicas para escolher, por
exemplo, qual classe instanciar ou a quais objetos delegar
responsabilidade. Esse padro nos mostra como estruturar e
encapsular essas decises. H cinco padres de criao GoF:
Abstract Factory, Builder, Factory Method, Prototype e Singleton.
Factory method
"Definir uma interface para criar um objeto mas deixar que subclasses
decidam que classe instanciar. Factory Method permite que uma classe
delegue a responsabilidade de instanciamento s subclasses."
[GoF]
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 et al, 1994].
Retornar uma instncia dentre muitas possveis classes, dependendo
dos dados providos a ele [Destro, 2004].
Motivao
til para se construir objetos individuais, para um propsito
especfico, sem que a construo requeira conhecimento das classes
especficas sendo instanciadas [Destro, 2004].
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 [Destro, 2004]. Por isso, este padro chamado de Factory
Method (traduzindo: mtodo-fbrica): um mtodo responsvel
pela fabricao de um objeto [Gamma et al, 1994].
Quando Usar
Quando uma classe no pode antecipar ou conhecer a classe dos
objetos que deve criar;
Quando uma classe quer suas subclasses para especificar os objetos
que cria;
Quando classes delegam responsabilidade alguma das vrias
subclasses ajudantes, e deseja-se localizar qual a subclasse
ajudante acessada.
Estrutura
Vantagens
Elimina a necessidade de acoplar classes especficas para aplicao
em nvel de cdigo [Gamma et al, 1994] na programao, lida-se
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.
Desvantagens
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 et al, 1994]. Entretanto, esta uma
soluo vivel se, e somente se, a especializao da classe do mtodo
fbrica no for estritamente necessrio (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 mtodofbrica em separado
Exemplo
Sistema de consulta de veculos: informa-se qual carro se deseja consultar,

ento as informaes dele so exibidas (adaptado [Destro, 2004]).
Continuao Exemplo
A classe Principal, ilustrada na Figura 2, a classe Java que inicializa a

execuo do aplicativo. PrincipalFrame a interface de entrada e em
CarroFrame as opes de consulta so exibidas. Selecionada a opo, o
mtodo-fbrica de CarroFactory invocado ( um mtodo esttico, o que
dispensa a instanciao da classe qual pertence). A opo escolhida em
CarroFrame passada como parmetro na invocao do mtodo-fbrica,
o que lhe permite identificar qual subclasse de Carro deve ser instanciada
(Gol, Golf, Vectra ou mega), contendo as informaes a serem
consultadas, como combustvel e preo.
Abstract Factory
"Prover uma interface para criar famlias de objetos relacionados ou

dependentes sem especificar suas classes concretas."
[GoF]
Propsito
Prover interfaces ou superclasses para a criao de objetos
relacionados ou dependentes, sem especificar a sua classe concreta
ou implementao [Gamma et al, 1994].
Retornar uma das muitas classes de objetos relacionadas, onde cada
uma delas pode retornar diferentes objetos quando requisitados
[Destro, 2004].
Motivao
Usada na criao de famlias de classes dependentes de uma interface ou
superclasse, com a estrutura bsica do padro Factory Method para fazer o
relacionamento entre as classes dependentes as suas respectivas
superclasses ou interfaces.
Da mesma maneira em que aparece no Factory Method, uma classe
criada contendo um mtodo que decide qual das opes de classes de
domnio retornar; entretanto no sero as classes simples a serem
escolhidas como opes, mas sim as famlias dessas classes, nas quais,
pode-se optar por quais classes internas a cada uma dessas famlias se
quer retornar.
Motivao
Em resumo, um nvel maior de abstrao criado [Destro, 2004]: no se
escolhe a classe de retorno dentro de uma famlia. Opta-se por uma das
classes de retorno e a sua famlia automaticamente retornada. Ou seja,
com base nos parmetros de retorno, uma classe buscada dentro de uma
das famlias disponveis, sem conhecer as estruturas de relacionamento
entre as classes e suas famlias.
Por isso, o mtodo tem o nome de Abstract Factory (fbrica abstrata),
pois pode atuar como uma fbrica de objetos genrica, recebendo um
grupo qualquer de objetos relacionados, que sero criados de maneira
transparente ao seu relacionamento.
Quando Usar
Situaes em que um sistema deve ser independente da maneira
como seus produtos so criados, relacionados e representados;
Quando necessria uma configurao utilizando uma das vrias
famlias de produtos;
No projeto de produtos que devem ser, obrigatoriamente, agrupados
em famlias e seu uso inerente a essa condio;
No fornecimento de uma biblioteca de classes de produtos, e devese revelar apenas suas interfaces ou superclasses, e no suas
implementaes ou subclasses.
Estrutura
Participantes
Super1: a classe abstrata (ou superclasse) dos objetos integrantes das
famlias.
Super2: a classe abstrata (ou superclasse) dos objetos representantes
das famlias.
Sub[1..4]: representam as diferentes classes sobre as quais se deve decidir
instanciar, normalmente indicados como produtos.
Sub[5,6]: representam as famlias, ou seja, classes que possuem
determinados produtos relacionados de maneira intrnseca elas.
AbstractFactory: nesta classe reside o mtodo decisrio, que avalia o
parmetro passado na sua invocao, para buscar um determinado produto
ou objeto, dentro das famlias, representadas por Sub5 e Sub6; ou seja
representa a fbrica abstrata.
Vantagens
Isola as classes concretas (subclasses ou implementaes) das suas
famlias e da fbrica abstrata, dessa maneira pode-se criar
produtos e associa-los famlia mais apropriada, alm de poder
acess-lo atravs da fbrica abstrata de forma transparente e
independente aos clientes do sistema;
Maior agilidade para alternar entre diferentes famlias de produtos:
possvel alternar entre diferentes famlias de produtos numa
aplicao, independente do nmero de produtos de cada famlia,
pois a fbrica de produtos cria uma famlia de produtos por
completo, podendo-se em seguida utilizar um ou vrios produtos
dessa famlia.
Vantagens
Maior segurana para trabalhar com produtos de uma mesma
famlia: como a classe fbrica abstrata instanciada uma nica
vez, assegura-se ao cliente da aplicao que se trabalhe com apenas
uma famlia de produtos por vez, pois uma fbrica abstrata pode
alternar entre vrias famlias de produtos, mas cria apenas uma
destas famlias por vez.
Desvantagens
O suporte a novos tipos de produtos se torna mais complicado
[Gamma, et al 1994], pois a fbrica abstrata somente suporta
famlias de produtos, ou seja, para a criao de novos produtos duas
alternativas de projeto podem ser seguidas: A criao de uma
famlia para suportar o novo produto, o que pode ser altamente
desfavorvel no caso de um nmero reduzido de novos produtos por
famlia criada.
A adaptao da fbrica abstrata para suportar um produto-solo,
que no integra nenhuma das famlias disponveis; entretanto isso
implica na modificao da fbrica abstrata e na inutilizao da
estrutura das famlias, o que descaracterizaria este padro.
Desvantagens
A interface grfica, quando houver, dever ser criada de maneira a
receber os produtos de forma genrica, o que cria impedimentos para
o tratamento grfico especializado dos produtos pela aplicao, pois
esta no deve saber qual dos produtos receber.
Exemplo
Continuao Exemplo
Carro e suas subclasses (Golf, Gol, Vectra e Omega), so

provenientes da estrutrura do Padro Factory Method, que parte
integrante de Abstract Factory. Fabricante tem o mesmo papel para
Volksvagen e Chevrolet do que Carro para suas respectivas
subclasses.
A classe Principal a classe Java que inicializa a execuo do

aplicativo. PrincipalFrame a interface de entrada e em
FabricanteFrame as opes de consulta so exibidas.
Continuao Exemplo
Selecionada a opo, FabricanteFactory, a fbrica abstrata,
instanciada. A opo escolhida em FabricanteFrame passada como
parmetro para a seleo do produto a ser instanciado, assim como
sua famlia, contendo as informaes a serem consultadas. As
famlias correspondem aos fabricantes (Volkswagen e Chevrolet) e
os produtos aos carros (Gol, Golf, Vectra ou mega); cada famlia
conta com dois produtos (Volkswagen: Gol e Golf, Chevrolet: Vectra
e mega). FabricanteFactory conhece apenas a interface das
famlias e esta, por sua vez, conhece apenas a interface dos
produtos.
Continuao Exemplo
Essas caractersticas acarretam algumas utilizaes recorrentes de
outros padres em AbstratctFactory:
Como a fbrica abstrata deve ser instanciada somente uma vez,
ela criada como um Singleton;
Para escolher os produtos, cada famlia conta com um mtodo
fbrica, pois conhece apenas a superclasse ou interface dos
produtos e no suas implementaes ou subclasses, o que denota a
utilizao do padro Factory Method;
Builder
"Separar a construo de um objeto complexo de sua representao para

que o mesmo processo de construo possa criar representaes
diferentes."
[GoF]
Propsito
Separar a construo de um objeto de sua respectiva representao,
e desta maneira, a partir dessa mesma construo, produzir
representaes diferentes [Gamma, et al, 1994].
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, 2004].
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.
Motivao
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.
Isto um pouco mais do que uma classe Factory, pois no retornam
objetos que so simplesmente descendentes de uma base, mas que
podem ser totalmente diferentes uns dos outros (por exemplo: telas
diferentes). Builder constri um nmero de objetos, de vrios
modos, dependendo dos dados recebidos [Destro, 2004].
Motivao
Para tal finalidade deve-se separar os atributos (que permanecem
residindo na estrutura da classe) dos seus mtodos (que passam a
integrar objetos em separado) [Destro, 2004], para que o corpo de
mtodos funcione como um captador de dados, e a classe como
um receptor, para instanciar um novo objeto, de acordo com o
que for recebido.
Quando Usar
Quando o algoritmo de criao de um objeto deve ser independente
das suas partes constituintes e da maneira como ele montado;
Para
que
processo
de
construo
permita
diferentes
representaes para o objeto que est sendo construdo;

Na simplificao de um objeto complexo, separando a sua
construo da sua constituio;
Estrutura
Participantes
uilder : a interface ou superclasse que contm os mtodos e atributos a
serem redefinidos. Ela oferece a parte da classe que deve ser comum s
construes que vo se seguir.
ub [n]: so as diversas construes (ou construtores) que podem ser obtidas

a partir de Builder, estas classes contm a definio do comportamento e
dos atributos que so desejveis aos produtos provenientes das aplicaes
que implementam este padro.
Participantes
roduto : o elemento que os construtores Sub[n] podem gerar, podendo ser
de um tipo nico, ou podem ser diferenciados, de acordo com a construo
que lhe inerente. O mais interessante e o que diferencia o padro
Builder do Abstract Factory que Produto no precisa ser uma instncia
das classes Sub[n]: pode se tratar de um objeto parte, sem nenhuma
relao classe-objeto com Sub[n] ou mesmo com a classe Builder.
Vantagens
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;
Desvantagens
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
Emisso de ordens de produo, baseadas em polticas de produo
variadas (adaptado [Metsker, 2004]).
Numa montadora de veculos, o processo de montagem de veculos
organizado com base em quatro parmetros especficos: modelo
(qual carro ser produzido), custo unitrio (custo de produo de
cada carro), quantidade (de modelos a ser produzida) e data de
entrega. Esses parmetros representam um documento: a ordem de
produo que orienta o processo de montagem dos veculos.
Exemplo
essa montadora, trabalha-se com o conceito de polticas de produo: a
maneira como se pode estabelecer regras para aceitar ou no uma ordem
de produo; so duas:
ormal: no aceita alteraes na ordem de produo, se ela no atende aos
requisitos mnimos.
lexvel: caso o nmero de carros e/ou o custo de produo sejam inferiores
ao mnimo estabelecido, eles so ajustados para que a ordem de produo
seja aceita.
Exemplo
essa montadora, trabalha-se com o conceito de polticas de produo: a
maneira como se pode estabelecer regras para aceitar ou no uma ordem
de produo; so duas:
ormal: no aceita alteraes na ordem de produo, se ela no atende aos
requisitos mnimos.
lexvel: caso o nmero de carros e/ou o custo de produo sejam inferiores
ao mnimo estabelecido, eles so ajustados para que a ordem de produo
seja aceita.
Exemplo
Exemplo
interface OPConstantes apenas disponibiliza constantes que so utilizadas
de maneira recorrente na aplicao, de maneira que podem ser acessadas
pelas classes que a implementam.
classe Principal, ilustrada na Figura 2, inicializa o aplicativo e
PrincipalFrame a interface de entrada do sistema. Em BuilderFrame
apresentada a tela para a insero de parmetros. OPAnalisador analisa os
parmetros e s permite a criao da ordem de produo se data e modelo
estiverem corretos, e conforme a poltica escolhida, instancia um dos
construtores de ordem de produo, que por sua vez criam uma ordem de
produo, que pode ser cadastrada ou no, conforme a maneira como cada
Exemplo
PBuilder a superclasse que disponibiliza para suas classes-filho as
caractersticas comuns de uma ordem de produo (quantidade de carros,
valor unitrio, etc.). OPBuilderInflex e OPBuilderFlex correspondem,
respectivamente construo da ordem de servio apenas com parmetros
completos e com alguns dos parmetros ausentes, dependendo do
parmetro passado em BuilderFrame, pelo usurio
Prototype
"Especificar os tipos de objetos a serem criados usando uma instncia como

prottipo e criar novos objetos ao copiar este prottipo."
[GoF]
Propsito
Especificar os tipos de objetos a serem criados, usando uma instncia
prototpica, criando novos objetos atravs da cpia desse prottipo
[Gamma et al, 1994].
Substituir a gerao de instncias no-inicializadas de uma classe,
fornecendo novos objetos a partir de uma classe-exemplo [Metsker,
2004].
Motivao
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.
ma 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.
Motivao
ntretanto, 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
[Metsker, 2004].
inda, 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.
Motivao
ara 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).
esse 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.
Motivao
lm de reduzir sensivelmente o nmero de classes [Gamma et al, 1994],
o uso desse padro isola o usurio da estrutura do objeto, ou a classeexemplo de seus produtos [Metsker, 2004] o que ainda facilita a criao
de novas classes-exemplo, quando for estritamente necessrio.
Quando Usar
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
Participantes
Sub [1..4]: representam as diferentes classes-exemplo sobre as
quais se deve decidir copiar. Elas implementaro uma interface
com o mtodo de clonagem, o que possibilita que a responsabilidade
do mtodo, e a deciso sobre o que clonar, fiquem isoladas.
InterfaceClonavel : interface Java que estende a classe Cloneable,
ou seja, oferece um mtodo de clonagem para ser redefinido
(duplicate), com um tipo de retorno que ser comum s classes que
a implementarem.
Participantes
Prototype : a classe que propriamente faz as cpias dos elementos
escolhidos; como o tipo de retorno proveniente da implementao de
uma interface padro, o objeto dessa classe faz as cpias de maneira
genrica, ou seja, sem conhecer o tipo de objeto que estar clonando.
Vantagens
Isolamento entre os produtos (subclasses ou implementaes) e suas
classes-exemplo [Metsker, 2004]; esta vantagem se d por dois
fatores:
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 [Gamma et al, 1994];
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.
Vantagens
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
[Gamma et al, 1994].
Desvantagens
nica desvantagem encontrada foi a da utilizao do mtodo Clone:
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 [Metsker, 2004];
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.
Desvantagens
ssim, 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) [Gamma
et al, 1994].
Exemplos
Linha de montagem de uma fbrica, onde um modelo de carro
especificado para a sua produo em srie [Tadarguila, 2005].
Exemplo
classe Principal, ilustrada na Figura 2 a classe Java que inicializa a
execuo do aplicativo. PrincipalFrame a interface de entrada e em
PrototypeFrame as opes de produo so exibidas.
elecionadas
as
opes,
classe
Prototype
instanciada
por
PrototypeFrame; esta classe recebe os parmetros para a clonagem:

modelo e nmero de unidades a serem produzidas a partir do modelo.
Exemplo
instncia de Protoytpe no sabe que classe de modelo ser clonada, e
nem como cada classe ser clonada. Essas responsabilidades so
inerentes s classes dos modelos (Gol, Golf, Vectra e Omega; Carro
apenas a superclasse para generalizar as caractersticas comuns dos
veculos, ela no participa desse Padro) isso feito pela maneira como
essas classes implementam a interface CarroClonavel, que por sua vez,
estende a classe nativa Cloneable que oferece um mtodo genrico de
cpia de objetos garantindo que as classes-exemplos (ou seja, as
classes dos modelos) no fiquem acopladas ao cliente (nesse caso, o
objeto da classe Prototype requisita as cpias, com base nos parmetros
passados).
Exemplo
rototype aciona o mtodo de clonagem, no objeto da classe-exemplo
passado como parmetro (isto significa o modelo) retornando um vetor
dinmico com o nmero de clones do modelo especificado. A classe Carro
no participa do padro, serve apenas como classe-pai das classesexemplo (o que caracteriza classes com o mesmo comportamento, mas
com atributos diferentes, j comentadas anteriormente)
Exemplo
ssas caractersticas acarretam algumas utilizaes recorrentes de outros
padres em conjunto com Prototype:
Apesar de serem muito parecidos, e, de certa maneira, parecerem
mtodos concorrentes, Prototype e AbstractFactory podem ser usados em
conjunto: uma fbrica abstrata pode ter um conjunto de prottipos,
dos quais pode obter cpias e retorna-las como produtos aos clientes
[Gamma et al, 1994];
Para a criao de interfaces grficas como em conjuntos de
visualizao e layout, por exemplo, um LookAndFeel Java Prototype
Singleton
"Garantir que uma classe s tenha uma nica instncia, e prover um ponto
de acesso global a ela."
[GoF]
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.
Motivao
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.
Quando Usar
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
Vantagens
cesso controlado instncia nica;
Singleton tem controle sobre como e quando clientes acessam a instncia;
spao de nomes reduzido;
Singleton melhor que variveis globais, j que as "globais" podem ser
encapsuladas na instncia nica, deixando um nico nome externo visvel;
ermite refinamento de operaes e de representao;
Exemplo
exemplo (adaptado [Destro, 2004]) utiliza um campo privado e esttico do
tipo da prpria classe para armazenar a referncia da nica instncia
permitida, o qual deve ser inicializado de modo a indicar a inexistncia de
tal instncia. Um mtodo esttico, cujo tipo de retorno tambm a prpria
classe, prov o ponto nico de acesso a tal instncia.
e a operao de instanciao ocorrer apenas na primeira solicitao de um

objeto da classe, garante-se que a instncia nica e ao mesmo tempo em
que
criao
ocorrer
quando
estritamente
necessrio
(lazy
instantiation).
Exemplo
Exemplo
Figura 3 ilustra a implementao do Padro de Projeto Singleton. A classe
DBConexao destinada a fornecer uma conexo nica para o Banco de
Dados especfico. Pelo uso desta classe pode-se reduzir a quantidade de
recursos utilizados por uma aplicao durante o acesso ao banco de dados,
garantindo uma nica conexo. Apenas por meio do mtodo getConexao()
possvel obter a referncia para a conexo nica. Existe um mtodo
adicional Shutdown() criado para garantir que a conexo seja encerrada
adequadamente. Note que so arbitrrias as definies de campos e
mtodos adicionais dentro de uma classe que pretende ser um Singleton,
devendo atender aos requisitos especficos da aplicao.
Exemplo
elo mtodo getConexao() da classe DBConexao obtm uma conexo para
o banco de dados (cujas strings referentes ao driver e url de conexo foram
inclusas diretamente no cdigo da classe). Por esta conexo, podem ser
estabelecidas sesses com o banco de dados, o que permite a execuo de
comandos SQL e processamento dos resultados obtidos. Tentativas de novas
conexes retornaro uma referncia para o mesmo objeto, reduzindo a
quantidade de recursos tomados do sistema.
travs da classe BDTesteConexao possvel extrair os dados do BD, nesta

classe encontra-se a SQL responsvel pela busca dos dados.
Exemplo
classe BDTela responsvel pela interface com o usurio, ela oferece os
quatro botes para conexo e um para desconexo. Todos os botes para
conexo tm a mesma finalidade, ou seja, conectar com o BD, mas caso j
exista um driver carregado para aquele BD, o mesmo somente ser
atualizado.
Padres Estruturais
definem caminhos comuns para a organizao de diferentes tipos de
objetos, facilitando sua integrao e colaborao mutua. H sete
padres estruturais GoF: ?? Bridge, Composite, Decorator, Facade,
Flyweight e Proxy
Decorator
"Anexar
responsabilidades
adicionais
a um
objeto
dinamicamente.
Decorators oferecem uma alternativa flexvel ao uso de herana para

estender uma funcionalidade."
[GoF]
Propsito
Agregar responsabilidades adicionais a um objeto dinamicamente.
Classes decoradoras oferecem uma alternativa flexvel ao uso de
herana para estender uma funcionalidade [Silva, 2005].
Motivao
Adicionar responsabilidades a um objeto, mas no sua classe.
Acontece, por exemplo, com criao de interfaces grficas, quando
se deseja acrescentar uma borda a um componente qualquer ou
uma barra de rolagem a uma rea de texto. Uma abordagem mais
flexvel inserir o componente em outro objeto que adiciona a
borda, um Decorator [Silva, 2005].
Quando Usar
Utilizado para adicionar responsabilidades a objetos individuais de
forma dinmica e transparente, isto , sem afetar outros objetos,
da mesma forma, quando se quer retirar responsabilidades.
Quando a utilizao de heranas para a implementao do mesmo

afetar a flexibilidade do sistema [Allen & Bambara, 2003].
Um caso de aplicao do Decorator quando existem muitas

variaes de um objeto. Imagine por exemplo uma classe Janela
com uma subclasse JanelaComBorda. Se houver a necessidade
tambm de janelas com rolagem, tem-se ainda JanelaComRolagem e
JanelaComBordaERolagem
[Faerman,
2005],
alm
de
outras
possveis combinaes, j que poderia haver menus, botes ou barra

de status.
Estrutura
Esse padro providencia que cada objeto Decorator contenha outro

objeto Decorator. Nesse aspecto, um decorator como um pequeno
composite cujos elementos possuem cada qual um filho nico.
Diferentemente do padro Composite, cujo propsito compor objetos
agregados, o propsito do Decorator compor comportamentos.
Estruturalmente, Figura 1, o padro Decorator dispe as classes em um

hierarquia e distribui operaes ao longo dela. Cada classe dessa
hierarquia tipicamente tem um construtor que precisa de outra
instncia de uma classe dela. As classes Decorator tipicamente
implementam suas operaes por meio da dependncia do objeto
decorador que recebem em seus construtores [Metsker, 2004].
Estrutura
Participantes
Componente : define a interface para objetos que podem ter
responsabilidades acrescentadas a eles dinamicamente.
ComponenteConcreto
define
um
objeto
para
qual
responsabilidades adicionais podem ser atribudas

Decorator : mantm uma referncia para um objeto Componente.
Define uma interface que segue a interface de Componente.
DecoratorConcretoA
DecoratorConcretoB:
acrescenta
responsabilidades ao componente
Vantagens
Fornece uma flexibilidade maior do que a herana esttica.
Evita a necessidade de colocar classes sobrecarregadas de recursos
em uma posio mais alta da hierarquia.
Simplifica a codificao permitindo que voc desenvolva uma srie
de classes com funcionalidades especficas, em vez de codificar
todo o comportamento no objeto.
Aprimora a extensibilidade do objeto, pois as alteraes so feitas
codificando novas classes.
Exemplos
Exemplos
O exemplo ilustrado na Figura 21, visa gerar janelas com caractersticas que
podem variar de uma janela para outra. Por exemplo, o cliente pode decidir
entre construir uma janela com barra de menus ou no. Desta forma
consegue-se aumentar o nmero de possibilidades de janelas diferentes
apresentadas com um pequeno nmero de classes.
Neste exemplo, a interface Janela recebe o papel de ser o Componente da

estrutura apresentada anteriormente. Por sua vez, JanelaComum interpreta
o ComponenteConcreto, ou seja, ele que receber as modificaes no
decorrer da execuo da aplicao. Como o prprio nome diz, o Decorator
assume a finalidade do Decorator da estrutura padro. JanelaMenuBar,
JanelaBorda,
JanelaBarraStatus
JanelaBarraFerramenta
herdam
de
Decorator, ou seja, so os n decoradores concretos.

Composite
"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.
[GoF]
Propsito
Compe objetos em estruturas do tipo rvore para representar
hierarquias todo-parte. Faz tambm com que o tratamento dos
objetos individuais e de suas composies seja uniforme.
Motivao
Aplicaes grficas como editores de desenho e sistemas de captura
de esquema deixam os usurios construrem diagramas complexos a
partir
de
Componentes
simples.
usurio
pode
agrupar
Componentes para formar Componentes maiores, que, por sua vez,

podem ser agrupados para formar Componentes maiores ainda. O
Padro Composite descreve como usar composio recursiva, de
modo que os clientes no tenham que fazer distino entre
componentes simples e composies. .
Quando Usar
Quiser representar hierarquias parte-todo de objetos;
Deseja que os clientes sejam capazes de ignorar as diferenas entre
composio de objetos e objetos individuais. Clientes trataro todos os
objetos uniformemente na estrutura Composite.
Estrutura
Participantes
Componente:
Declara a interface para objetos na composio;
Implementa comportamento default para interface comum a todas as
classes, como apropriado;
Declara uma interface para acessar ou gerenciar seus Componentes
filhos;
Folha:
Representa objetos folhas na composio. Uma folha no tem filhos;
Define comportamento para objetos primitivos na composio.
Participantes
Composio:
Define comportamento para Componentes que tm filhos;
Armazena Componentes filhos;
Implementa operaes relacionadas com filhos na interface do
Componente.
Cliente:
Manipula objetos na composio atravs da interface Componente.
Vantagens
Define a consistncia das hierarquias de classes de objetos primitivos e
objetos composio.
Clientes podem tratar estruturas compostas e objetos individuais
uniformemente. Clientes normalmente no sabem (e no deveriam se
preocupar) se eles esto tratando com uma folha ou uma composio;
Torna
mais
fcil
adicionar
novos
tipos
de
Componentes.
Novas
composies ou subclasses. Folhas trabalham automaticamente com

estruturas existentes e cdigo do cliente. Clientes no tm que ser
mudados para novas classes de Componentes
Desvantagens
Quando uma composio tem apenas alguns Componentes, voc ter de
usar uma checagem em tempo de execuo para isto.
Adapter
Converter a interface de uma classe em outra interface esperada pelos

clientes. Adapter permite a comunicao entre classes que no poderiam
trabalhar juntas devido incompatibilidade de suas interfaces."
[GoF]
Propsito
O principal objetivo do Adapter facilitar 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. s vezes preciso
modificar uma classe que no pode ser alterada adequadamente
devido falta do cdigo fonte (alguma biblioteca de classes
comercial), ou por alguma outra razo. O Adapter uma das formas
de modificar classes nestas circunstncias, sendo classificado com a
de finalidade estrutural e abrange tanto escopo de classe quanto de
objeto.
Motivao
Uma classe j existente e sua interface no combinam com a
esperada pelo cliente;
Se quer criar uma classe reutilizvel que coopera com classes no
relacionadas
ou
no
previstas,
isto
classes
que
no
necessariamente tenham interfaces compatveis;

Se necessita usar vrias subclasses existentes, mas impraticvel
adaptar suas interfaces fazendo um Subclassing de cada uma
Quando Usar
Desejar usar uma classe existente e sua interface no corresponde ao que
voc precisa;
Desejar criar uma classe reutilizvel que coopera com classes imprevistas
ou no relacionveis, isto , classes que no tem necessariamente
interfaces compatveis
Estrutura
Participantes
Cliente : Colabora entre os objetos conforme a interface Alvo.
Alvo : Define a interface de domnio especfico que o Cliente utiliza.
Adaptador : Adapta a ClasseExistente para ser utilizada pela classe

Alvo.
ClasseExistente : Define uma interface pr-existente que necessita

ser adaptada.
Vantagens
Adapta o Adaptador para o Alvo atravs de uma classe concreta.

Como consequncia, uma classe adaptada no funcionar para
adaptar uma classe e suas subclasses.
Deixa o Adaptador sobrepor algum comportamento do adaptado,

desde que o Adaptador seja uma subclasse do adaptado.
Introduz um nico objeto e nenhum ponteiro adicional necessrio

para chegar ao adaptado
Exemplo
Exemplo
Usou-se como exemplo (adaptado [Software Design Patterns, 2005]), ilustrado na

Figura 2, uma implementao que demonstra o uso de um banco de dados qumico
legado. Objetos da classe CompostoQuimico acessam o banco de dados atravs de
uma interface que utiliza o Padro Adapter.
CompostoQumico : Define a interface de domnio especfico que o cliente

utiliza, ou seja, esta classe contm somente o que a classe Tela conhece.
Composto : Adapta a interface CompostoQuimico para ser utilizada pela

classe BDQuimico, para posteriormente os dados sejam mostrados na tela.
BDQuimico : Define uma interface pr-existente que necessita ser adaptada,

neste exemplo ela armazena os dados de cada composto qumico, que so
acessados e adaptados para a tela cliente.
Bridge
"Desacoplar uma abstrao de sua implementao para que os dois possam

variar independentemente."
[GoF]
Propsito
Desacopla uma abstrao de sua implementao de maneira que
ambas possam variar independentemente.
Motivao
O que motiva a utilizao do padro Bridge a necessidade de um
driver, permitindo implementaes especficas para tratar objetos
em diferentes meios persistentes.
Quando Usar
Quando for necessrio evitar uma ligao permanente entre a

interface e a implementao.
Quando alteraes na implementao no puderem afetar clientes.
Quando
implementaes
so
compartilhadas
entre
objetos
desconhecidos do cliente
Estrutura
Participantes
Abstrao : Define a interface de abstrao. Mantm uma referncia a um

objeto do tipo Implementador.
AbstracoRefinada : Estende a interface definida por Abstrao.
Implementador : Define a interface para classes de implementao. Esta

no tem a obrigao de corresponder exatamente interface de
abstrao. De fato, as duas interfaces podem ser bastante diferentes.
Tipicamente, a interface de implementao fornece apenas operaes
primitivas, cabendo abstrao a responsabilidade de definir operaes
de alto nvel baseadas nestas primitivas.
ImplementadorConcretoA e implementadorComcretoB : Implementao

concreta da interface definida por Implementador.
Vantagens
Detalhes de implementao totalmente inacessveis aos clientes.
Eliminao
de
dependncias
em
tempo
de
compilao
das
implementaes.
Implementao de abstrao pode ser configurada em tempo de

execuo.
Exemplo
Exemplo
A implementao (adaptado [Software Design Patterns, 2005]) do Padro Bridge

ilustra a Ponte entre a classe abstrata ObetoNegocios a ClienteDadosObjeto atravs
de interface DadosObjeto. A interface DadosObjeto no igual a ObjetoNegocios,
j que no existe necessria dependncia entre elas.
Este exemplo demonstra desacoplamento de uma abstrao de ObjetoNegocio da

implementao em DadosObjeto. As implementaes de DadosObjeto podem
evoluir dinamicamente sem propagar mudanas a nenhum dos objetos cliente, isso
pode ser verificado na figura 2.
Na classe ClienteDadosObjeto encontra-se a implementao que a classe cliente

espera atravs da DadosObjeto, neste caso, ela contm algumas pessoas
cadastradas, ela pode adicionar novas pessoas em determinado grupo ou mostrlas. Para interagir entre os cadastros utiliza-se o Padro Iterator, que ser
detalhado nos prximos Padres.
Proxy
"Prover um substituto ou ponto atravs do qual um objeto possa controlar

o acesso a outro."
[GoF]
Quando usar
antagens
Transparncia: mesma sintaxe usada na comunicao entre o cliente e
sujeito real usada no proxy
Permite o tratamento inteligente dos dados no cliente
Permite maior eficincia com caching no cliente
esvantagens
Possvel impacto na performance
Transparncia nem sempre 100% (fatores externos como queda da
rede podem tornar o proxy inoperante ou desatualizado)
Problema
istema quer utilizar objeto real...
as ele no est disponvel (remoto, inaccessvel, ...)
oluo: arranjar um intermedirio que saiba se comunicar com ele

eficientemente
Faade
"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."
[GoF]
Propsito
ferecer uma interface nica para um conjunto de interfaces de um
subsistema.
efinir uma interface de nvel mais elevado que torna o subsistema mais
fcil de usar [Silva, 2005].
eduzir a complexidade do relacionamento entre uma classe relativa ao
cliente e as demais classes utilitrias [Junior, 2004].
Motivao
ma grande vantagem da programao orientada a objetos que ela ajuda a
evitar que as aplicaes se tornem programas monolticos, com pedaos
incorrigivelmente entrelaados. No entanto, a aplicabilidade variada das
classes em um subsistema orientado a objetos pode oferecer uma
variedade expressiva de opes [Metsker, 2004].
xistem circunstncias onde necessrio utilizar diversas classes diferentes
para que uma tarefa possa ser completada, caracterizando uma situao
onde uma classe cliente necessita utilizar objetos de um conjunto
especfico de classes utilitrias que, em conjunto, compem um subsistema
particular ou que representam o acesso a diversos
subsistemas distintos
Motivao
Quando usar?
riao de interfaces mais simples para um ou mais subsistemas complexos.
eduo de dependncia entre o cliente e as classes existentes nos
subsistemas, ocasionando a reduo da coeso do sistema
riao de sistemas em camadas. Este padro prov o ponto de entrada para
cada camada (nvel) do subsistema.
Vantagens
rotege os clientes da complexidade dos componentes do subsistema;
romove acoplamento fraco entre o subsistema e seus clientes;
eduz dependncias de compilao, possivelmente complexas ou circulares;
acilita a portabilidade do sistema [Junior, 2004];
eduz a unio entre subsistemas desde que cada subsistema utilize seu
prprio padro Facade e outras partes do sistema utilizem o padro Facade
para comunicar-se com o subsistema [Allen e Bambara,
2003];
Flyweight
"Usar compartilhamento para suportar grandes quantidades de objetos

refinados eficientemente."
[GoF]
Prs e contras
uando usar Flyweight
Quando o tamanho do conjunto de objetos for significativamente
menor que a quantidade de vezes em que eles so usados na aplicao
Quando objetos podem ser usados em diferentes contextos ao mesmo
tempo (agindo sempre como um objeto independente)
uando no usar
Quando o estado dos objetos no for imutvel ( preciso passar o
estado mutvel como parmetro e isto pode ser impraticvel se o
estado consistir de vrios objetos)
Quando for necessrio elaborar um algoritmo
ouESTRUTURAIS
algo complicado
PADRES
GOF AULApara
RAV1
Problema
Padres Comportamentais
so projetados para organizar, gerenciar e combinar diferentes
comportamentos. H 11 padres comportamentais GoF: Chain of
Responsibility, Command, Interpreter, Iterator, Mediator, Memento,
Observer, State, Strategy, Template Method e Visitor.
Interpreter
"Dada uma linguagem, definir uma representao para sua gramtica junto
com um interpretador que usa a representao para interpretar sentenas
na linguagem.
[GoF]
Interpreter
Descreve como projetar um conjunto de classes para representar e

interpretar uma gramtica para linguagens simples
Sua aplicao recomenda naquelas situaes em que h necessidade de

interpretar uma linguagem qualquer e ao mesmo tempo quando se quer
representar sentenas da linguagem como rvores abstratas sintticas
Template Method
"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."
[GoF]
Template Method
ornece uma estrutura fixa, de um algoritmo, esta parte fixa deve estar
presente na superclasse, sendo obrigatrio uma classeAbstrata que possa
conter um mtodo concreto, pois em uma interface s possvel conter
mtodos abstratos que definem um comportamento, esta a vantagem de
ser uma Classe Abstrata porque tambm ir fornecer mtodos abstratos s
suas subclasses, que por sua vez herdam este mtodo, por Herana
(programao), e devem implementar os mtodos abstratos fornecendo um
comportamento concreto aos mtodos que foram definidos como abstratos.
Com
isso
certas
partes,
do
algoritmo,
sero
preenchidos
por
implementaes que iro variar, ou seja, implementar um algoritmo em

um mtodo, postergando a definio de alguns passos do algoritmo, para
Quando usar
Quando a estrutura fixa de um algoritmo puder ser definida pela

superclasse deixando certas partes para serem preenchidos por
implementaes que podem variar
Estrutura
Chain of Responsability
"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."
[GoF]
Propsito
No conhecer de antemo qual objeto ir responder a uma determinada

requisio.
Compor os objetos em cascata e passar a requisio pela corrente at que um

objeto a sirva [Silva, 2005].
Evitar a unio entre o remetente de uma solicitao e seu receptor, dando aos
diversos objetos uma chance de tratar da solicitao [Allen & Bambara, 2003].
Motivao
Em projetos orientados a objetos manter os objetos com acoplamento fraco,

mantendo especfica e mnima a responsabilidade entre eles, faz com que
mudanas sejam inseridas com menos risco de falhas. Os clientes apenas enxergam
a
interface
visvel
do
objeto
permanecerem
isolados
de
detalhes
de
implementao [Metsker, 2004].
Uma mquina de refrigerantes necessita armazenar em locais diferentes cada tipo

de moeda possvel. Pode ser til que um objeto receba a moeda, mas se ele no
for capaz de armazenar no local correto, passe-o para outro objeto buscando a
colocao correta da moeda [Silva, 2005]. Isso um exemplo de tentativa de
desacoplamento, j que se algum no pode resolver determinada tarefa ocorre
uma delegao da responsabilidade para outro objeto de forma totalmente
transparente.
Quando usar
Mais de um objeto pode tratar de uma solicitao e este desconhecido.
Uma solicitao deve ser emitida para um entre os vrios objetos e o
receptor, no sendo especificado explicitamente.
O conjunto de objetos capaz de tratar da solicitao deve ser especificado
dinamicamente.
Estrutura
Participantes
limentador : define a interface para tratar as solicitaes e implementa a
referncia ao sucessor (opcional).
limentadorConcretoA, ..., AlimentadorConcretoN : trata as solicitaes
pelas
quais
responsvel.
Pode
acessar
seu
sucessor.
Se
AlimentadorConcreto pode tratar a solicitao, ele assim o faz; caso

contrrio ele repassa a solicitao para o seu sucessor.
liente : Inicia a solicitao para um objeto AlimentadorConcreto da cadeia.
GOF AULA RAV1
equisio : As instncias de Requisio PADRES
que ESTRUTURAIS
iram transportar
as
Vantagens
vita acoplamento do transmissor de um requisio com seus receptores,
fazendo com que mais de um projeto tenha a chance de manipular a
requisio.
ncadeia os objetos receptores e passa a requisio ao longo dessa cadeia
at que um objeto possa manipul-lo.
eduz a vinculao.
diciona flexibilidade.
Exemplo
o exemplo ilustrado na Figura 2, a implementao relacionada a uma
mquina de refrigerantes, na qual vai-se adicionando moedas at o valor
do refrigerante ser alcanado para a sua aquisio.
classes
contidas
dentro
do
pacote
moedas
so
os
AlimentadoresConcretos, enquando Moeda a requisio enviada.
Exemplo
Exemplo
omo existem infinitos tipos de moedas, pois possvel encontrar moedas
tanto as que esto em circulao em nosso pas, como as que esto em
circulao nas mais de outras duzentas naes, alm das moedas que j so
antigas e no possui mais validade monetria, a mquina de refrigerantes
tem que descobrir qual moeda entrou atravs de possveis padres, como
por exemplo, a espessura, raio e peso.
este exemplo, a cada moeda que entra - a cada requisio - uma classe
alimentadora analisa a moeda e busca ver se est dentro dos seus padres,
caso no esteja, vai passar para alguma outra classe alimentadora at que
seja descoberta qual moeda entrou. Caso no se encaixe em nenhuma das
Bibliografia
Utilizando UML e Padres: uma introduo anlise e ao
projeto orientados a objetos - 3 Edio
Autor: Larman, Craig
Padres de Projeto: solues reutilizveis de software

orientado a objetos
Autor: Gamma, Erich ... [et al]

Revisaoav 1

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Revisaoav 1

Transféré par

Droits d'auteur :

Formats disponibles

PADRES DE PROJETO DE SOFTWARE

Aula Reviso Padres estruturais GoF

PADRES DE PROJETO DE SOFTWARE

O que veremos nesta terceira aula

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

Padres so comuns em vrias reas da engenharia;

Design Patterns, ou Padres de Projeto;

PADRES DE PROJETO DE SOFTWARE

"Cada padro descreve um problema que ocorre repetidas vezes em nosso

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

"Os padres de projeto so descries de objetos que se comunicam e

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

Classificao dos 23 padres segundo GoF*

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

Em alguns casos, pode ser criada uma relao superclasse-subclasse para a

PADRES DE PROJETO DE SOFTWARE

Sistema de consulta de veculos: informa-se qual carro se deseja consultar,

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

A classe Principal, ilustrada na Figura 2, a classe Java que inicializa a

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

"Prover uma interface para criar famlias de objetos relacionados ou

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE

PADRES DE PROJETO DE SOFTWARE

PADRES DE PROJETO DE SOFTWARE

PADRES ESTRUTURAIS GOF AULA RAV1

PADRES DE PROJETO DE SOFTWARE