Revisão - Padrões de Projeto de Software

Prévia do material em texto

PADRÕES DE PROJETO DE SOFTWARE
Aula Revisão – Padrões estruturais GoF 
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
O que veremos nesta terceira aula
 Revisão para AV1
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Introdução
• Projetar software OO reusável e de boa qualidade é uma tarefa
difícil;
• Para realizar essa tarefa a contento, projetistas experientes usam
soluções de sucesso com as quais já trabalharam no passado;
• Isso leva à descoberta de padrões de projeto;
• Durante duas décadas, a comunidade de padrões vem se desenvolvendo
de acordo com essa dinâmica.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
O que é um padrão?
• Maneira testada ou documentada de alcançar um objetivo qualquer;
• Padrões são comuns em várias áreas da engenharia;
• Design Patterns, ou Padrões de Projeto;
• Padrões para alcançar objetivos na engenharia de software usando
classes e métodos em linguagens orientadas a objeto;
• Inspirado em "A Pattern Language" de Christopher Alexander, sobre
padrões de arquitetura de cidades, casas e prédios;
• "Design Patterns" de Erich Gamma, John Vlissides, Ralph Jonhson e
Richard Helm, conhecidos como "The Gang of Four", ou GoF,
descreve 23 padrões de projeto úteis
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
O que é um padrão?
"Cada padrão descreve um problema que ocorre repetidas vezes em nosso
ambiente, e então descreve o núcleo da solução para aquele problema, de
tal maneira que pode-se usar essa solução milhões de vezes sem nunca
fazê-la da mesma forma duas vezes"
Christopher Alexander, sobre padrões em Arquitetura
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
O que é um padrão?
"Os padrões de projeto são descrições de objetos que se comunicam e
classes que são customizadas para resolver um problema genérico de
design em um contexto específico"
Gamma, Helm, Vlissides & Johnson, sobre padrões em software
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Catálogos de padrões
Um catálogo de padrões é um grupo de padrões que estão 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)
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Catálogo - GoF
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Classificação dos 23 padrões segundo GoF*
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Padrões de Criação
• fornecem um guia de como instanciar objetos. Esta ação
normalmente envolve decisões dinâmicas para escolher, por
exemplo, qual classe instanciar ou a quais objetos delegar
responsabilidade. Esse padrão nos mostra como estruturar e
encapsular essas decisões. Há cinco padrões de criação GoF:
Abstract Factory, Builder, Factory Method, Prototype e Singleton.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
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]
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Propósito
• Definir uma interface ou classe abstrata para a criação de um
objeto, permitindo decidir qual das implementações ou subclasses
devem ser instanciadas; deixa uma classe deferir instanciação para
subclasses [Gamma et al, 1994].
• Retornar uma instância dentre muitas possíveis classes, dependendo
dos dados providos a ele [Destro, 2004].
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Motivação
• Útil para se construir objetos individuais, para um propósito
específico, sem que a construção requeira conhecimento das classes
específicas sendo instanciadas [Destro, 2004].
• Uma classe de abstração é criada, contendo um método em que
decide qual das opções de classe retornar. Então, apenas este
método é invocado, sem conhecer a classe que será retornada por
ele [Destro, 2004]. Por isso, este padrão é chamado de Factory
Method (traduzindo: “método-fábrica”): um método é responsável
pela “fabricação” de um objeto [Gamma et al, 1994].
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Quando Usar
• Quando uma classe não 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 várias
subclasses ajudantes, e deseja-se localizar qual é a subclasse
ajudante acessada.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Estrutura
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Vantagens
• Elimina a necessidade de acoplar classes específicas para aplicação
em nível de código [Gamma et al, 1994] – na programação, lida-se
apenas com a superclasse ou interface, para conhecer os métodos e
atributos de uma forma genérica, o que permite manipular as
subclasses ou implementações de maneira particular.
• Dá maior flexibilidade para as classes – criar objetos numa classe
que possui o “método-fábrica” é sempre mais flexível que fazê-lo
em separado, assim o “método-fábrica” funciona como uma conexão
para que uma das subclasses possa prover uma versão estendida de
um objeto.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Desvantagens
• Em alguns casos, pode ser criada uma relação superclasse-subclasse para a
criação de classes que suportam o “método-fábrica”, e de acordo com a
classe a ser criada, uma das várias subclasses podem sobrescrever o
“método-fábrica”, a fim de conectar hierarquias de classes paralelas e
fornecer maior portabilidade [Gamma et al, 1994]. Entretanto, esta é uma
solução viável se, e somente se, a especialização da classe do método
fábrica não for estritamente necessário (como no caso de um número
elevado de implementações diferentes para o “método-fábrica”). Caso
contrário, a relação custo-planejamento-implementação 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 criação classes para o “método-
fábrica” em separado
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
• Sistema de consulta de veículos: informa-se qual carro se deseja consultar,
então as informações dele são exibidas (adaptado [Destro, 2004]).
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Continuação Exemplo
• A classe Principal, ilustrada na Figura 2, é a classe Java que inicializa a
execução do aplicativo. PrincipalFrame é a interface de entrada e em
CarroFrame as opções de consulta são exibidas. Selecionada a opção, o
“método-fábrica” de CarroFactory é invocado (é um método estático, o que
dispensa a instanciação da classe à qual pertence). A opção escolhida em
CarroFrame é passada como parâmetro na invocação do “método-fábrica”,
o que lhe permite identificar qual subclasse de Carro deve ser instanciada
(Gol, Golf, Vectra ou Ômega), contendo as informações a serem
consultadas, como combustível e preço.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Abstract Factory
"Prover uma interface para criar famílias de objetos relacionados ou
dependentes sem especificar suas classes concretas."
[GoF]
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Propósito
• Prover interfaces ou superclasses para a criação de objetos
relacionados ou dependentes, sem especificar a sua classe concreta
ou implementação [Gamma et al, 1994].
• Retornar uma dasmuitas classes de objetos relacionadas, onde cada
uma delas pode retornar diferentes objetos quando requisitados
[Destro, 2004].
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Motivação
• Usada na criação de famílias de classes dependentes de uma interface ou
superclasse, com a estrutura básica do padrão 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 método que decide qual das opções de classes de
domínio retornar; entretanto não serão as classes simples a serem
escolhidas como opções, mas sim as famílias dessas classes, nas quais,
pode-se optar por quais classes internas a cada uma dessas famílias se quer
retornar.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Motivação
• Em resumo, um nível maior de abstração é criado [Destro, 2004]: não se
escolhe a classe de retorno dentro de uma família. Opta-se por uma das
classes de retorno e a sua família é automaticamente retornada. Ou seja,
com base nos parâmetros de retorno, uma classe é buscada dentro de uma
das famílias disponíveis, sem conhecer as estruturas de relacionamento
entre as classes e suas famílias.
• Por isso, o método tem o nome de Abstract Factory (“fábrica abstrata”),
pois pode atuar como uma fábrica de objetos genérica, recebendo um
grupo qualquer de objetos relacionados, que serão criados de maneira
transparente ao seu relacionamento.
•
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Quando Usar
• Situações em que um sistema deve ser independente da maneira
como seus produtos são criados, relacionados e representados;
• Quando é necessária uma configuração utilizando uma das várias
famílias de produtos;
• No projeto de produtos que devem ser, obrigatoriamente, agrupados
em famílias e seu uso é inerente a essa condição;
• No fornecimento de uma biblioteca de classes de produtos, e deve-
se revelar apenas suas interfaces ou superclasses, e não suas
implementações ou subclasses.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Estrutura
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Participantes
• Super1: é a classe abstrata (ou superclasse) dos objetos integrantes das
famílias.
• Super2: é a classe abstrata (ou superclasse) dos objetos representantes das
famílias.
• Sub[1..4]: representam as diferentes classes sobre as quais se deve decidir
instanciar, normalmente indicados como produtos.
• Sub[5,6]: representam as famílias, ou seja, classes que possuem
determinados produtos relacionados de maneira intrínseca à elas.
• AbstractFactory: nesta classe reside o método decisório, que avalia o
parâmetro passado na sua invocação, para buscar um determinado produto
ou objeto, dentro das famílias, representadas por Sub5 e Sub6; ou seja
representa a “fábrica abstrata”.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Vantagens
• Isola as classes concretas (subclasses ou implementações) das suas
famílias e da “fábrica abstrata”, dessa maneira pode-se criar
produtos e associa-los à família mais apropriada, além de poder
acessá-lo através da “fábrica abstrata” de forma transparente e
independente aos clientes do sistema;
• Maior agilidade para alternar entre diferentes famílias de produtos:
é possível alternar entre diferentes famílias de produtos numa
aplicação, independente do número de produtos de cada família,
pois a “fábrica de produtos” cria uma família de produtos por
completo, podendo-se em seguida utilizar um ou vários produtos
dessa família.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Vantagens
• Maior segurança para trabalhar com produtos de uma mesma
família: como a classe “fábrica abstrata” é instanciada uma única
vez, assegura-se ao cliente da aplicação que se trabalhe com apenas
uma família de produtos por vez, pois uma “fábrica abstrata” pode
alternar entre várias famílias de produtos, mas cria apenas uma
destas famílias por vez.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Desvantagens
• O suporte a novos tipos de produtos se torna mais complicado
[Gamma, et al 1994], pois a “fábrica abstrata” somente suporta
famílias de produtos, ou seja, para a criação de novos produtos duas
alternativas de projeto podem ser seguidas: ◦A criação de uma
família para suportar o novo produto, o que pode ser altamente
desfavorável no caso de um número reduzido de novos produtos por
família criada.
• A adaptação da “fábrica abstrata” para suportar um “produto-solo”,
que não integra nenhuma das famílias disponíveis; entretanto isso
implica na modificação da “fábrica abstrata” e na inutilização da
estrutura das famílias, o que descaracterizaria este padrão.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Desvantagens
• A interface gráfica, quando houver, deverá ser criada de maneira a
receber os produtos de forma genérica, o que cria impedimentos para o
tratamento gráfico especializado dos produtos pela aplicação, pois esta
não deve saber qual dos produtos receberá.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Continuação Exemplo
• Carro e suas subclasses (Golf, Gol, Vectra e Omega), são
provenientes da estrutrura do Padrão 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 execução do
aplicativo. PrincipalFrame é a interface de entrada e em
FabricanteFrame as opções de consulta são exibidas.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Continuação Exemplo
• Selecionada a opção, FabricanteFactory, a “fábrica abstrata”, é
instanciada. A opção escolhida em FabricanteFrame é passada como
parâmetro para a seleção do produto a ser instanciado, assim como
sua família, contendo as informações a serem consultadas. As
famílias correspondem aos fabricantes (Volkswagen e Chevrolet) e os
produtos aos carros (Gol, Golf, Vectra ou Ômega); cada família
conta com dois produtos (Volkswagen: Gol e Golf, Chevrolet: Vectra
e Ômega). FabricanteFactory conhece apenas a interface das
famílias e esta, por sua vez, conhece apenas a interface dos
produtos.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Continuação Exemplo
• Essas características acarretam algumas utilizações recorrentes de
outros padrões em AbstratctFactory:
• Como a “fábrica abstrata” deve ser instanciada somente uma vez,
ela é criada como um Singleton;
• Para escolher os produtos, cada família conta com um “método
fábrica”, pois conhece apenas a superclasse ou interface dos
produtos e não suas implementações ou subclasses, o que denota a
utilização do padrão Factory Method;
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Builder
"Separar a construção de um objeto complexo de sua representação para
que o mesmo processo de construção possa criar representações
diferentes."
[GoF]
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Propósito
• Separar a construção de um objeto de sua respectiva representação,
e desta maneira, a partir dessa mesma construção, produzir
representações diferentes [Gamma, et al, 1994].
• Mover a lógica de construção de uma classe para um objeto externo,
a fim de reduzir a complexidade da mesma e permitir a construção
gradual de objetos-alvo a partir dessa classe [Metsker, 2004].
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Motivação
• Nem sempre é fácil coletar os requisitos que movem a criação de
uma classe. Mais trabalhoso é, porém, instanciar objetos de uma
classe que variem de acordo com os requisitos apresentados.Por
exemplo, mudar o layout de uma tela, em tempo de execução,
quando o usuário seleciona uma opção condizente.
• Mas, se fosse possível separar da classe os seus métodos –
representam o comportamento e a construção dessa classe – numa
estrutura de dados a parte, seria possível também, utilizar essa
estrutura para coletar as opções de um cliente e construir objetos
diferentes, conhecendo apenas os parâmetros necessários para esta
construção, provenientes dos atributos que compõem a classe em
questão.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Motivação
• Desta maneira se apresenta o padrão Builder, um construtor de
objetos, baseado nos métodos de criação e comportamento de uma
classe, que pode instanciar objetos diferentes, conhecendo apenas
os atributos que compõem a classe em questão.
• Isto é um pouco mais do que uma classe Factory, pois não retornam
objetos que são simplesmente descendentes de uma base, mas que
podem ser totalmente diferentes uns dos outros (por exemplo: telas
diferentes). Builder constrói um número de objetos, de vários
modos, dependendo dos dados recebidos [Destro, 2004].
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Motivação
• Para tal finalidade deve-se separar os atributos (que permanecem
residindo na estrutura da classe) dos seus métodos (que passam a
integrar objetos em separado) [Destro, 2004], para que o corpo de
métodos funcione como um “captador” de dados, e a classe como
um “receptor”, para instanciar um novo objeto, de acordo com o
que for recebido.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Quando Usar
• Quando o algoritmo de criação de um objeto deve ser independente
das suas partes constituintes e da maneira como ele é “montado”;
• Para que o processo de construção permita diferentes
representações para o objeto que está sendo construído;
• Na simplificação de um objeto complexo, separando a sua
“construção” da sua “constituição”;
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Estrutura
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Participantes
•
uilder : é a interface ou superclasse que contém os métodos e atributos a
serem redefinidos. Ela oferece a “parte” da classe que deve ser comum às
construções que vão se seguir.
•
ub [n]: são as diversas construções (ou construtores) que podem ser obtidas
a partir de Builder, estas classes contém a definição do comportamento e
dos atributos que são desejáveis aos produtos provenientes das aplicações
que implementam este padrão.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
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 construção
que lhe é inerente. O mais interessante – e o que diferencia o padrão
Builder do Abstract Factory – é que Produto não precisa ser uma instância
das classes Sub[n]: pode se tratar de um objeto à parte, sem nenhuma
relação classe-objeto com Sub[n] ou mesmo com a classe Builder.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Vantagens
•Redução da extensão e da complexidade de uma classe;
•Independência entre a representação de um objeto e a sua construção;
•Criação de regras graduais de construção para um objeto;
•Geração de construções diversificadas de um tipo de objeto, ou de
construções de objetos diversificados entre si, a partir de um
construtor-base;
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Desvantagens
•Por ser bastante flexível, este padrão só apresentará desvantagem se o
seu construtor-base for mal planejado, o que poderia resultar em
construções redundantes ou com baixo aproveitamento operacional.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
• Emissão de ordens de produção, baseadas em políticas de produção
variadas (adaptado [Metsker, 2004]).
• Numa montadora de veículos, o processo de montagem de veículos é
organizado com base em quatro parâmetros específicos: modelo
(qual carro será produzido), custo unitário (custo de produção de
cada carro), quantidade (de modelos a ser produzida) e data de
entrega. Esses parâmetros representam um documento: a ordem de
produção que orienta o processo de montagem dos veículos.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
•
essa montadora, trabalha-se com o conceito de políticas de produção: a
maneira como se pode estabelecer regras para aceitar ou não uma ordem
de produção; são duas:
•
ormal: não aceita alterações na ordem de produção, se ela não atende aos
requisitos mínimos.
•
lexível: caso o número de carros e/ou o custo de produção sejam inferiores
ao mínimo estabelecido, eles são ajustados para que a ordem de produção
seja aceita.
•
penas se deve notar que não cabem ajustes aos parâmetros data (que deve
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
•
essa montadora, trabalha-se com o conceito de políticas de produção: a
maneira como se pode estabelecer regras para aceitar ou não uma ordem
de produção; são duas:
•
ormal: não aceita alterações na ordem de produção, se ela não atende aos
requisitos mínimos.
•
lexível: caso o número de carros e/ou o custo de produção sejam inferiores
ao mínimo estabelecido, eles são ajustados para que a ordem de produção
seja aceita.
•
penas se deve notar que não cabem ajustes aos parâmetros data (que deve
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
•
interface OPConstantes apenas disponibiliza constantes que são utilizadas
de maneira recorrente na aplicação, 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 inserção de parâmetros. OPAnalisador analisa os
parâmetros e só permite a criação da ordem de produção se data e modelo
estiverem corretos, e conforme a política escolhida, instancia um dos
construtores de ordem de produção, que por sua vez criam uma ordem de
produção, que pode ser cadastrada ou não, conforme a maneira como cada
construtor cria a ordem de produção analisando os parâmetros recebidos
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
•
PBuilder é a superclasse que disponibiliza para suas “classes-filho” as
características comuns de uma ordem de produção (quantidade de carros,
valor unitário, etc.). OPBuilderInflex e OPBuilderFlex correspondem,
respectivamente à construção da ordem de serviço apenas com parâmetros
completos e com alguns dos parâmetros ausentes, dependendo do
parâmetro passado em BuilderFrame, pelo usuário
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Prototype
"Especificar os tipos de objetos a serem criados usando uma instância como
protótipo e criar novos objetos ao copiar este protótipo."
[GoF]
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Propósito
•Especificar os tipos de objetos a serem criados, usando uma instância
prototípica, criando novos objetos através da cópia desse protótipo
[Gamma et al, 1994].
•Substituir a geração de instâncias não-inicializadas de uma classe,
fornecendo novos objetos a partir de uma classe-exemplo [Metsker,
2004].
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Motivação
•
criação de classes se faz mais simples quando é possível partir de um
exemplo, para então criar as especializações condizentes com as
necessidades do domínio da aplicação.
•
ma alternativa é criar classes especializadas que herdem, ou seja, que
sejam subclasses, de uma classe com atributos e métodos mais genéricos
(ou até mesmo uma classe abstrata)com parâmetros de visibilidade
acessíveis, alterando-os apenas quando for preciso na criação da classe
especializada.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Motivação
•
ntretanto, essa alternativa apresenta um problema de ordem prática: a
geração excessiva de classes especializadas (ou subclasses), para cada
necessidade específica, 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 criação de subclasses, estas
devem conhecer a superclasse que lhes fornecerá as características
comuns a elas, para que, então, sejam diferenciadas, segundo as
necessidades de cada objeto.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Motivação
•
ara sistemas remotos, nem sempre isso é possível: na maioria das
situações, um servidor de classes fica isolado dos clientes, e estes não
podem conhecer a estrutura da superclasse; apenas podem saber dos
parâmetros – a serem informados em chamadas de métodos – que
participam da criação de produtos (que no caso, seriam as subclasses).
•
esse contexto, Prototype se dispõe a simplificar a criação de novas
classes a partir de uma classe-exemplo, copiando-a fielmente, para que,
nessa cópia, sejam feitas as especializações intrínsecas a cada
dependência da aplicação.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Motivação
•
lém de reduzir sensivelmente o número de classes [Gamma et al, 1994], o
uso desse padrão isola o usuário da estrutura do objeto, ou a classe-
exemplo de seus produtos [Metsker, 2004] – o que ainda facilita a criação
de novas classes-exemplo, quando for estritamente necessário.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Quando Usar
• Quando as classes para instanciação são especificadas em tempo de
execução ou carregadas dinamicamente;
• Para evitar a construção de uma hierarquia de classes-exemplo
estritamente especializada ou demasiadamente ligada a um tipo de
produto;
• Quando as instâncias de uma classe podem ter apenas uma ou
poucas maneiras de manifestar seu estado.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Estrutura
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Participantes
• Sub [1..4]: representam as diferentes classes-exemplo sobre as quais
se deve decidir “copiar”. Elas implementarão uma interface com o
método de clonagem, o que possibilita que a responsabilidade do
método, e a decisão sobre “o que clonar”, fiquem isoladas.
• InterfaceClonavel : interface Java que estende a classe Cloneable,
ou seja, oferece um método de clonagem para ser redefinido
(duplicate), com um tipo de retorno que será comum às classes que
a implementarem.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Participantes
•Prototype : É a classe que propriamente “faz as cópias” dos elementos
escolhidos; como o tipo de retorno é proveniente da implementação de
uma interface padrão, o objeto dessa classe faz as cópias de maneira
genérica, ou seja, sem conhecer o tipo de objeto que estará clonando.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Vantagens
• Isolamento entre os produtos (subclasses ou implementações) e suas
classes-exemplo [Metsker, 2004]; esta vantagem se dá por dois
fatores:
 Facilita a criação de novas classes-exemplo – quando for
devidamente necessário – menos acopladas, o que é apropriado
para classes que diferem apenas em seus atributos, mas não em
seus comportamentos [Gamma et al, 1994];
 Fornece de forma transparente e independente acesso ao
sistema, apenas pelo conhecimento dos parâmetros necessários
para a criação das cópias, a partir das classes exemplo.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Vantagens
• Redução do número de subclasses: as cópias podem suprir as
especializações – sejam elas por herança ou por implementação de
interfaces – pois uma vez criadas com um formato padrão, podem
ser modificadas dentro de cada contexto e necessidade inerentes à
aplicação.
• Configuração para o carregamento dinâmico de novas classes: com
este padrão, é possível configurar a instanciação de classes que
originalmente não estavam ligadas ao programa, pois ao invés de
invocar um construtor estático, dá suporte à criação de instâncias
em tempo de execução, assim que sua respectiva classe é carregada
[Gamma et al, 1994].
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Desvantagens
•
única desvantagem encontrada foi a da utilização do método Clone:
 Este método cria uma cópia exata de um objeto que lhe for passado
como parâmetro. Uma cópia exata carrega consigo uma espécie de
“fotografia” do objeto: não apenas seu comportamento é “clonado”,
mas também 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 não um “objeto novo”, o que significa
uma cópia não-instanciada daquele objeto, ou com os campos
ajustados para valores iniciais, que sejam default para toda a
aplicação.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Desvantagens
•
ssim, o programador deve ter em mente esta diferença ao implementar
este padrão, pois objetos clonados podem apresentar problemas de
inclusão de classes não existentes e/ou referencias circulares
(dependências de parâmetros ou resultados que sejam internos aos
objetos e que não sejam levados em consideração na clonagem) [Gamma
et al, 1994].
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplos
Linha de montagem de uma fábrica, onde um modelo de carro é
especificado para a sua produção em série [Tadarguila, 2005].
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
•
classe Principal, ilustrada na Figura 2 é a classe Java que inicializa a
execução do aplicativo. PrincipalFrame é a interface de entrada e em
PrototypeFrame as opções de produção são exibidas.
•
elecionadas as opções, a classe Prototype é instanciada por
PrototypeFrame; esta classe recebe os parâmetros para a clonagem:
modelo e número de unidades a serem produzidas a partir do modelo.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
•
instância de Protoytpe não sabe que classe de modelo será clonada, e
nem como cada classe será clonada. Essas responsabilidades são
inerentes às classes dos modelos (Gol, Golf, Vectra e Omega; Carro é
apenas a superclasse para generalizar as características comuns dos
veículos, ela não participa desse Padrão) – isso é feito pela maneira como
essas classes implementam a interface CarroClonavel, que por sua vez,
estende a classe nativa Cloneable que oferece um método genérico de
cópia de objetos – garantindo que as classes-exemplos (ou seja, as classes
dos modelos) não fiquem acopladas ao cliente (nesse caso, o objeto da
classe Prototype requisita as cópias, com base nos parâmetros passados).
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
•
rototype aciona o método de clonagem, no objeto da classe-exemplo
passado como parâmetro (isto significa o “modelo”) retornando um vetor
dinâmico com o número de clones do modelo especificado. A classe Carro
não participa do padrão, serve apenas como “classe-pai” das “classes-
exemplo” (o que caracteriza classes com o mesmo comportamento, mas
com atributos diferentes, já comentadas anteriormente)
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
•
ssas características acarretam algumas utilizações recorrentes de outros
padrões em conjunto com Prototype:
•
Apesar de serem muito parecidos, e, de certa maneira, parecerem
métodos concorrentes, Prototype e AbstractFactory podem ser usados em
conjunto: uma “fábrica abstrata” podeter um conjunto de “protótipos”,
dos quais pode obter cópias e retorna-las como produtos aos clientes
[Gamma et al, 1994];
•
Para a criação de interfaces gráficas – como em conjuntos de visualização
e layout, por exemplo, um LookAndFeel Java – Prototype potencializa a
produtividade dos padrões Composite e Decorator
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Singleton
"Garantir que uma classe só tenha uma única instância, e prover um ponto
de acesso global a ela."
[GoF]
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Propósito
• Padrão de projeto simples que ilustra várias características
necessárias aos padrões de projeto. Classificado criacional, pois está
relacionado com processo de criação de objetos, possuindo inúmeras
aplicações e implementação bastante direta.
• Tem como propósito garantir a existência de uma instância única de
uma classe específica, que possa ser acessada de maneira global e
uniforme.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Motivação
• O que motiva sua existência é que muitas aplicações necessitam
garantir a ocorrência de uma instância de classes específicas, pois
tais objetos podem fazer uso de recursos cuja utilização deve ser
exclusiva, ou porque se deseja que os demais elementos do sistema
compartilhem um único objeto particular.
• Estas situações ocorrem quando vários subsistemas utilizam um
único arquivo de configuração, permitindo sua modificação
concorrente. Ou quando só se deve estabelecer uma conexão
exclusiva com um banco de dados ou um sistema remoto, devendo
ser compartilhado por várias tarefas paralelas; entre muitas outras.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Motivação
• Ao mesmo tempo não se quer que os usuários destas classes zelem
por esta condição de unicidade, mas se deseja oferecer acesso
simples à instância única que deverá existir, portanto se adiciona
estas responsabilidades às classes que deverão constituir um
Singleton.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Quando Usar
• Haver uma única instância de uma classe e esta deve ser acessada a
partir de um ponto de acesso bem-conhecido
• A instância única deve ser extensível através de subclasses e clientes
podem usar instâncias diferentes polimorficamente, sem
modificação de código.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Estrutura
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Vantagens
•
cesso controlado à instância única;
•
Singleton tem controle sobre como e quando clientes acessam a instância;
•
spaço de nomes reduzido;
•
Singleton é melhor que variáveis globais, já que as "globais" podem ser
encapsuladas na instância única, deixando um único nome externo visível;
•
ermite refinamento de operações e de representação;
•
árias classes Singleton (relacionadas ou não via herança) podem obedecer a
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
•
exemplo (adaptado [Destro, 2004]) utiliza um campo privado e estático do
tipo da própria classe para armazenar a referência da única instância
permitida, o qual deve ser inicializado de modo a indicar a inexistência de
tal instância. Um método estático, cujo tipo de retorno também é a própria
classe, provê o ponto único de acesso a tal instância.
•
e a operação de instanciação ocorrer apenas na primeira solicitação de um
objeto da classe, garante-se que a instância é única e ao mesmo tempo em
que à criação só ocorrerá quando estritamente necessário (lazy
instantiation).
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
•
Figura 3 ilustra a implementação do Padrão de Projeto Singleton. A classe
DBConexao é destinada a fornecer uma conexão única para o Banco de
Dados específico. Pelo uso desta classe pode-se reduzir a quantidade de
recursos utilizados por uma aplicação durante o acesso ao banco de dados,
garantindo uma única conexão. Apenas por meio do método “getConexao()”
é possível obter a referência para a conexão única. Existe um método
adicional “Shutdown()” criado para garantir que a conexão seja encerrada
adequadamente. Note que são arbitrárias as definições de campos e
métodos adicionais dentro de uma classe que pretende ser um Singleton,
devendo atender aos requisitos específicos da aplicação.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
•
elo método “getConexao()” da classe DBConexao obtém uma conexão para
o banco de dados (cujas strings referentes ao driver e url de conexão foram
inclusas diretamente no código da classe). Por esta conexão, podem ser
estabelecidas sessões com o banco de dados, o que permite a execução de
comandos SQL e processamento dos resultados obtidos. Tentativas de novas
conexões retornarão uma referência para o mesmo objeto, reduzindo a
quantidade de recursos tomados do sistema.
•
través da classe BDTesteConexao é possível extrair os dados do BD, nesta
classe encontra-se a SQL responsável pela busca dos dados.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
•
classe BDTela é responsável pela interface com o usuário, ela oferece os
quatro botões para conexão e um para desconexão. Todos os botões para
conexão têm a mesma finalidade, ou seja, conectar com o BD, mas caso já
exista um driver carregado para aquele BD, o mesmo somente será
atualizado.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Padrões Estruturais
• definem caminhos comuns para a organização de diferentes tipos de
objetos, facilitando sua integração e colaboração mutua. Há sete
padrões estruturais GoF: ?? Bridge, Composite, Decorator, Facade,
Flyweight e Proxy
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Decorator
"Anexar responsabilidades adicionais a um objeto dinamicamente.
Decorators oferecem uma alternativa flexível ao uso de herança para
estender uma funcionalidade."
[GoF]
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Propósito
• Agregar responsabilidades adicionais a um objeto dinamicamente.
Classes decoradoras oferecem uma alternativa flexível ao uso de
herança para estender uma funcionalidade [Silva, 2005].
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Motivação
• Adicionar responsabilidades a um objeto, mas não à sua classe.
Acontece, por exemplo, com criação de interfaces gráficas, quando
se deseja acrescentar uma borda a um componente qualquer ou uma
barra de rolagem a uma área de texto. Uma abordagem mais flexível
é inserir o componente em outro objeto que adiciona a borda, um
Decorator [Silva, 2005].
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Quando Usar
• Utilizado para adicionar responsabilidades a objetos individuais de
forma dinâmica e transparente, isto é, sem afetar outros objetos, da
mesma forma, quando se quer retirar responsabilidades.
• Quando a utilização de heranças para a implementação do mesmo
afetará a flexibilidade do sistema [Allen & Bambara, 2003].
• Um caso de aplicação do Decorator é quando existem muitas
variações de um objeto. Imagine por exemplo uma classe Janela
com uma subclasse JanelaComBorda. Se houver a necessidade
também de janelas com rolagem, tem-se ainda JanelaComRolagem e
JanelaComBordaERolagem [Faerman, 2005], além de outras possíveis
combinações, já que poderia haver menus, botões ou barra de
status.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Estrutura
• Esse padrão 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 padrão Composite, cujo propósito é compor objetos
agregados, o propósito do Decoratoré compor comportamentos.
• Estruturalmente, Figura 1, o padrão Decorator dispõe as classes em um
hierarquia e distribui operações ao longo dela. Cada classe dessa
hierarquia tipicamente tem um construtor que precisa de outra
instância de uma classe dela. As classes Decorator tipicamente
implementam suas operações por meio da dependência do objeto
decorador que recebem em seus construtores [Metsker, 2004].
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Estrutura
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Participantes
• Componente : define a interface para objetos que podem ter
responsabilidades acrescentadas a eles dinamicamente.
• ComponenteConcreto : define um objeto para o qual
responsabilidades adicionais podem ser atribuídas
• Decorator : mantém uma referência para um objeto Componente.
Define uma interface que segue a interface de Componente.
• DecoratorConcretoA e DecoratorConcretoB: acrescenta
responsabilidades ao componente
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Vantagens
• Fornece uma flexibilidade maior do que a herança estática.
• ◦ Evita a necessidade de colocar classes sobrecarregadas de recursos
em uma posição mais alta da hierarquia.
• ◦ Simplifica a codificação permitindo que você desenvolva uma série
de classes com funcionalidades específicas, em vez de codificar todo
o comportamento no objeto.
• ◦ Aprimora a extensibilidade do objeto, pois as alterações são feitas
codificando novas classes.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplos
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplos
• O exemplo ilustrado na Figura 21, visa gerar janelas com características que
podem variar de uma janela para outra. Por exemplo, o cliente pode decidir
entre construir uma janela com barra de menus ou não. Desta forma
consegue-se aumentar o número de possibilidades de janelas diferentes
apresentadas com um pequeno número 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 modificações no
decorrer da execução da aplicação. Como o próprio nome diz, o Decorator
assume a finalidade do Decorator da estrutura padrão. JanelaMenuBar,
JanelaBorda, JanelaBarraStatus e JanelaBarraFerramenta herdam de
Decorator, ou seja, são os n decoradores concretos.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Composite
"Compor objetos em estruturas de árvore para representar hierarquias
todo-parte. Composite permite que clientes tratem objetos individuais e
composições de objetos de maneira uniforme.“
[GoF]
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Propósito
• Compõe objetos em estruturas do tipo árvore para representar
hierarquias todo-parte. Faz também com que o tratamento dos
objetos individuais e de suas composições seja uniforme.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Motivação
• Aplicações gráficas como editores de desenho e sistemas de captura
de esquema deixam os usuários construírem diagramas complexos a
partir de Componentes simples. O usuário pode agrupar
Componentes para formar Componentes maiores, que, por sua vez,
podem ser agrupados para formar Componentes maiores ainda. O
Padrão Composite descreve como usar composição recursiva, de
modo que os clientes não tenham que fazer distinção entre
componentes simples e composições. .
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Quando Usar
• Quiser representar hierarquias parte-todo de objetos;
• Deseja que os clientes sejam capazes de ignorar as diferenças entre
composição de objetos e objetos individuais. Clientes tratarão todos os
objetos uniformemente na estrutura Composite.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Estrutura
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Participantes
• Componente:
• Declara a interface para objetos na composição;
• 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 composição. Uma folha não tem filhos;
• Define comportamento para objetos primitivos na composição.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Participantes
• Composição:
• Define comportamento para Componentes que têm filhos;
• Armazena Componentes filhos;
• Implementa operações relacionadas com filhos na interface do
Componente.
• • Cliente:
• Manipula objetos na composição através da interface Componente.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Vantagens
• Define a consistência das hierarquias de classes de objetos primitivos e
objetos composição.
• Clientes podem tratar estruturas compostas e objetos individuais
uniformemente. Clientes normalmente não sabem (e não deveriam se
preocupar) se eles estão tratando com uma folha ou uma composição;
• Torna mais fácil adicionar novos tipos de Componentes. Novas composições
ou subclasses. Folhas trabalham automaticamente com estruturas
existentes e código do cliente. Clientes não têm que ser mudados para
novas classes de Componentes
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Desvantagens
• Quando uma composição tem apenas alguns Componentes, você terá de
usar uma checagem em tempo de execução para isto.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Adapter
“Converter a interface de uma classe em outra interface esperada pelos
clientes. Adapter permite a comunicação entre classes que não poderiam
trabalhar juntas devido à incompatibilidade de suas interfaces."
[GoF]
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Propósito
• O principal objetivo do Adapter é facilitar a conversão da interface
de uma classe para outra interface mais interessante para o cliente,
fazendo com que várias classes possam trabalhar em conjunto
independentemente das interfaces originais. Às vezes é preciso
modificar uma classe que não pode ser alterada adequadamente
devido à falta do código fonte (alguma biblioteca de classes
comercial), ou por alguma outra razão. O Adapter é uma das formas
de modificar classes nestas circunstâncias, sendo classificado com a
de finalidade estrutural e abrange tanto escopo de classe quanto de
objeto.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Motivação
• Uma classe já existente e sua interface não combinam com a
esperada pelo cliente;
• Se quer criar uma classe reutilizável que coopera com classes não
relacionadas ou não previstas, isto é, classes que não
necessariamente tenham interfaces compatíveis;
• Se necessita usar várias subclasses existentes, mas é impraticável
adaptar suas interfaces fazendo um Subclassing de cada uma
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Quando Usar
• Desejar usar uma classe existente e sua interface não corresponde ao que
você precisa;
• Desejar criar uma classe reutilizável que coopera com classes imprevistas
ou não relacionáveis, isto é, classes que não tem necessariamente
interfaces compatíveis
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Estrutura
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Participantes
• Cliente : Colabora entre os objetos conforme a interface Alvo.
• Alvo : Define a interface de domínio específico que o Cliente utiliza.
• Adaptador : Adapta a ClasseExistente para ser utilizada pela classe
Alvo.
• ClasseExistente : Define uma interface pré-existente que necessita
ser adaptada.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Vantagens
• Adapta o Adaptadorpara o Alvo através de uma classe concreta. Como
consequência, uma classe adaptada não 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 é necessário
para chegar ao adaptado
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
• Usou-se como exemplo (adaptado [Software Design Patterns, 2005]), ilustrado na
Figura 2, uma implementação que demonstra o uso de um banco de dados químico
legado. Objetos da classe CompostoQuimico acessam o banco de dados através de
uma interface que utiliza o Padrão Adapter.
• CompostoQuímico : Define a interface de domínio específico que o cliente
utiliza, ou seja, esta classe contém 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 químico, que são
acessados e adaptados para a tela cliente.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Bridge
"Desacoplar uma abstração de sua implementação para que os dois possam
variar independentemente."
[GoF]
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Propósito
• Desacopla uma abstração de sua implementação de maneira que
ambas possam variar independentemente.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Motivação
• O que motiva a utilização do padrão Bridge é a necessidade de um
driver, permitindo implementações específicas para tratar objetos
em diferentes meios persistentes.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Quando Usar
• Quando for necessário evitar uma ligação permanente entre a
interface e a implementação.
• Quando alterações na implementação não puderem afetar clientes.
• Quando implementações são compartilhadas entre objetos
desconhecidos do cliente
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Estrutura
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Participantes
• Abstração : Define a interface de abstração. Mantém uma referência a
um objeto do tipo Implementador.
• AbstracãoRefinada : Estende a interface definida por Abstração.
• Implementador : Define a interface para classes de implementação. Esta
não tem a obrigação de corresponder exatamente à interface de
abstração. De fato, as duas interfaces podem ser bastante diferentes.
Tipicamente, a interface de implementação fornece apenas operações
primitivas, cabendo à abstração a responsabilidade de definir operações
de alto nível baseadas nestas primitivas.
• ImplementadorConcretoA e implementadorComcretoB : Implementação
concreta da interface definida por Implementador.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Vantagens
• Detalhes de implementação totalmente inacessíveis aos clientes.
• Eliminação de dependências em tempo de compilação das
implementações.
• Implementação de abstração pode ser configurada em tempo de
execução.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
• A implementação (adaptado [Software Design Patterns, 2005]) do Padrão Bridge
ilustra a Ponte entre a classe abstrata ObetoNegocios a ClienteDadosObjeto através
de interface DadosObjeto. A interface DadosObjeto não é igual a ObjetoNegocios,
já que não existe necessária dependência entre elas.
• Este exemplo demonstra desacoplamento de uma abstração de ObjetoNegocio da
implementação em DadosObjeto. As implementações de DadosObjeto podem
evoluir dinamicamente sem propagar mudanças a nenhum dos objetos cliente, isso
pode ser verificado na figura 2.
• Na classe ClienteDadosObjeto encontra-se a implementação que a classe cliente
espera através da DadosObjeto, neste caso, ela contém algumas pessoas
cadastradas, ela pode adicionar novas pessoas em determinado grupo ou mostrá-
las. Para interagir entre os cadastros utiliza-se o Padrão Iterator, que será
detalhado nos próximos Padrões.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Proxy
"Prover um substituto ou ponto através do qual um objeto possa controlar
o acesso a outro."
[GoF]
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Quando usar
•
antagens
 Transparência: mesma sintaxe usada na comunicação entre o cliente e
sujeito real é usada no proxy
 Permite o tratamento inteligente dos dados no cliente
 Permite maior eficiência com caching no cliente
•
esvantagens
 Possível impacto na performance
 Transparência nem sempre é 100% (fatores externos como queda da
rede podem tornar o proxy inoperante ou desatualizado)
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Problema
•
istema quer utilizar objeto real...
•
as ele não está disponível (remoto, inaccessível, ...)
•
olução: arranjar um intermediário que saiba se comunicar com ele
eficientemente
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Façade
"Oferecer uma interface única para um conjunto de interfaces de um
subsistema. Façade define uma interface de nível mais elevado que torna o
subsistema mais fácil de usar."
[GoF]
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Propósito
•
ferecer uma interface única para um conjunto de interfaces de um
subsistema.
•
efinir uma interface de nível mais elevado que torna o subsistema mais
fácil de usar [Silva, 2005].
•
eduzir a complexidade do relacionamento entre uma classe relativa ao
cliente e as demais classes utilitárias [Junior, 2004].
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Motivação
•
ma grande vantagem da programação orientada a objetos é que ela ajuda a
evitar que as aplicações se tornem programas monolíticos, com pedaços
incorrigivelmente entrelaçados. No entanto, a aplicabilidade variada das
classes em um subsistema orientado a objetos pode oferecer uma
variedade expressiva de opções [Metsker, 2004].
•
xistem circunstâncias onde é necessário utilizar diversas classes diferentes
para que uma tarefa possa ser completada, caracterizando uma situação
onde uma classe cliente necessita utilizar objetos de um conjunto
específico de classes utilitárias que, em conjunto, compõem um subsistema
particular ou que representam o acesso a diversos subsistemas distintos
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Motivação
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Quando usar?
•
riação de interfaces mais simples para um ou mais subsistemas complexos.
•
edução de dependência entre o cliente e as classes existentes nos
subsistemas, ocasionando a redução da coesão do sistema
•
riação de sistemas em camadas. Este padrão provê o ponto de entrada para
cada camada (nível) do subsistema.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Vantagens
•
rotege os clientes da complexidade dos componentes do subsistema;
•
romove acoplamento fraco entre o subsistema e seus clientes;
•
eduz dependências de compilação, possivelmente complexas ou circulares;
•
acilita a portabilidade do sistema [Junior, 2004];
•
eduz a união entre subsistemas desde que cada subsistema utilize seu
próprio padrão Facade e outras partes do sistema utilizem o padrão Facade
para comunicar-se com o subsistema [Allen e Bambara 2003];
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Flyweight
"Usar compartilhamento para suportar grandes quantidades de objetos
refinados eficientemente."
[GoF]PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Prós e contras
•
uando usar Flyweight
 Quando o tamanho do conjunto de objetos for significativamente
menor que a quantidade de vezes em que eles são usados na aplicação
 Quando objetos podem ser usados em diferentes contextos ao mesmo
tempo (agindo sempre como um objeto independente)
•
uando não usar
 Quando o estado dos objetos não for imutável (é preciso passar o
estado mutável como parâmetro e isto pode ser impraticável se o
estado consistir de vários objetos)
 Quando for necessário elaborar um algoritmo ou algo complicado para
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Problema
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Padrões Comportamentais
• são projetados para organizar, gerenciar e combinar diferentes
comportamentos. Há 11 padrões comportamentais GoF: Chain of
Responsibility, Command, Interpreter, Iterator, Mediator, Memento,
Observer, State, Strategy, Template Method e Visitor.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Interpreter
"Dada uma linguagem, definir uma representação para sua gramática junto
com um interpretador que usa a representação para interpretar sentenças
na linguagem.“
[GoF]
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Interpreter
• Descreve como projetar um conjunto de classes para representar e
interpretar uma gramática para linguagens simples
• Sua aplicação é recomenda naquelas situações em que há necessidade de
interpretar uma linguagem qualquer e ao mesmo tempo quando se quer
representar sentenças da linguagem como árvores abstratas sintáticas
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Template Method
"Definir o esqueleto de um algoritmo dentro de uma operação, 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]
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Template Method
•
ornece uma estrutura fixa, de um algoritmo, esta parte fixa deve estar
presente na superclasse, sendo obrigatório uma classeAbstrata que possa
conter um método concreto, pois em uma interface só é possível conter
métodos abstratos que definem um comportamento, esta é a vantagem de
ser uma Classe Abstrata porque também irá fornecer métodos abstratos às
suas subclasses, que por sua vez herdam este método, por Herança
(programação), e devem implementar os métodos abstratos fornecendo um
comportamento concreto aos métodos que foram definidos como abstratos.
Com isso certas partes, do algoritmo, serão preenchidos por
implementações que irão variar, ou seja, implementar um algoritmo em um
método, postergando a definição de alguns passos do algoritmo, para que
outras classes possam redefiní los
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Quando usar
• Quando a estrutura fixa de um algoritmo puder ser definida pela
superclasse deixando certas partes para serem preenchidos por
implementações que podem variar
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Estrutura 
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Chain of Responsability
"Evita acoplar o remetente de uma requisição ao seu destinatário ao dar a
mais de um objeto a chance de servir a requisição. Compõe os objetos em
cascata e passa a requisição pela corrente até que um objeto a sirva."
[GoF]
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Propósito
• Não conhecer de antemão qual objeto irá responder a uma determinada
requisição.
• Compor os objetos em cascata e passar a requisição pela corrente até que um
objeto a sirva [Silva, 2005].
• Evitar a união entre o remetente de uma solicitação e seu receptor, dando aos
diversos objetos uma chance de tratar da solicitação [Allen & Bambara, 2003].
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Motivação
• Em projetos orientados a objetos manter os objetos com acoplamento fraco,
mantendo específica e mínima a responsabilidade entre eles, faz com que
mudanças sejam inseridas com menos risco de falhas. Os clientes apenas enxergam
a interface visível do objeto permanecerem isolados de detalhes de
implementação [Metsker, 2004].
• Uma máquina de refrigerantes necessita armazenar em locais diferentes cada tipo
de moeda possível. Pode ser útil que um objeto receba a moeda, mas se ele não
for capaz de armazenar no local correto, passe-o para outro objeto buscando a
colocação correta da moeda [Silva, 2005]. Isso é um exemplo de tentativa de
desacoplamento, já que se alguém não pode resolver determinada tarefa ocorre
uma delegação da responsabilidade para outro objeto de forma totalmente
transparente.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Quando usar
• Mais de um objeto pode tratar de uma solicitação e este é desconhecido.
• Uma solicitação deve ser emitida para um entre os vários objetos e o
receptor, não sendo especificado explicitamente.
• O conjunto de objetos capaz de tratar da solicitação deve ser especificado
dinamicamente.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Estrutura
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Participantes
•
limentador : define a interface para tratar as solicitações e implementa a
referência ao sucessor (opcional).
•
limentadorConcretoA, ..., AlimentadorConcretoN : trata as solicitações
pelas quais é responsável. Pode acessar seu sucessor. Se o
AlimentadorConcreto pode tratar a solicitação, ele assim o faz; caso
contrário ele repassa a solicitação para o seu sucessor.
•
liente : Inicia a solicitação para um objeto AlimentadorConcreto da cadeia.
•
equisição : As instâncias de Requisição é que iram transportar as
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Vantagens
•
vita acoplamento do transmissor de um requisição com seus receptores,
fazendo com que mais de um projeto tenha a chance de manipular a
requisição.
•
ncadeia os objetos receptores e passa a requisição ao longo dessa cadeia
até que um objeto possa manipulá-lo.
•
eduz a vinculação.
•
diciona flexibilidade.
•
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
•
o exemplo ilustrado na Figura 2, a implementação é relacionada a uma
máquina de refrigerantes, na qual vai-se adicionando moedas até o valor
do refrigerante ser alcançado para a sua aquisição.
•
s classes contidas dentro do pacote “moedas” são os
AlimentadoresConcretos, enquando Moeda é a requisição enviada.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
•
omo existem infinitos tipos de moedas, pois é possível encontrar moedas
tanto as que estão em circulação em nosso país, como as que estão em
circulação nas mais de outras duzentas nações, além das moedas que já são
antigas e não possui mais validade monetária, a máquina de refrigerantes
tem que descobrir qual moeda entrou através de possíveis padrões, como
por exemplo, a espessura, raio e peso.
•
este exemplo, a cada moeda que entra - a cada requisição - uma classe
alimentadora analisa a moeda e busca ver se está dentro dos seus padrões,
caso não esteja, vai passar para alguma outra classe alimentadora até que
seja descoberta qual moeda entrou. Caso não se encaixe em nenhuma das
especificações a moeda será descartada e não será computado valor
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Bibliografia
Utilizando UML e Padrões: uma introdução à análise e ao
projeto orientados a objetos- 3ª Edição
Autor: Larman, Craig
Padrões de Projeto: soluções reutilizáveis de software
orientado a objetos
Autor: Gamma, Erich ... [et al]
PADRÕES DE PROJETO DE SOFTWARE
Aula RAV2 – Revisão
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
O que veremos nesta terceira aula
 Revisão para AV2 e AV3
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Classificação dos padrões GoF segundo Metsker [2]
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Command
"Encapsular uma requisição como um objeto, permitindo que clientes
parametrizem diferentes requisições, filas ou requisições de log, e
suportar operações reversíveis.“
[GoF]
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Estrutura
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo padrão Command
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Iterator
"Prover uma maneira de acessar os elementos de um objeto agregado
sequencialmente sem expor sua representação interna."
[GoF]
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Problema
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo 
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Mediator
"Definir um objeto que encapsula como um conjunto de objetos interagem.
Mediator promove acoplamento fraco ao manter objetos que não se
referem um ao outro explicitamente, permitindo variar sua interação
independentemente."
[GoF]
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Problema
• Como permitir que um grupo de objetos se comunique entre si sem que
haja acoplamento entre eles?
• Como remover o forte acoplamento presente em relacionamentos muitos
para muitos?
• Como permitir que novos participantes sejam ligados ao grupo facilmente?
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Solução
• Introduzir um mediador
• Objetos podem se comunicar sem se conhecer
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Memento
"Sem violar o encapsulamento, capturar e externalizar o estado interno de
um objeto para que o objeto possa ter esse estado restaurado
posteriormente."
[GoF]
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Problema
• É preciso guardar informações sobre um objeto suficientes para desfazer
uma operação, mas essas informações não devem ser públicas
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Estrutura
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Visitor
"Representar uma operação a ser realizada sobre os elementos de uma
estrutura de objetos. Visitor permite definir uma nova operação sem
mudar as classes dos elementos nos quais opera “
[GoF]
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Problema
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo 1
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo 3
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Observer
"Definir uma dependência um-para-muitos entre objetos para que quando
um objeto mudar de estado, todos os seus dependentes sejam notificados
e atualizados automaticamente."
[GoF]
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo 
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
State
"Permitir a um objeto alterar o seu comportamento quanto o seu estado
interno mudar. O objeto irá aparentar mudar de classe."
[GoF]
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Problema
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Strategy
"Definir uma família de algoritmos, encapsular cada um, e fazê-los
intercambiáveis. Strategy permite que algoritmos mudem
independentemente entre clientes que os utilizam."
[GoF]
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Problema
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo 1
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Padrões GRASP
• A qualidade de um projeto orientado a objetos está fortemente
relacionada com a distribuição de responsabilidades
• As responsabilidades de um projeto podem ser divididas em
“conhecer” e “fazer” (Larman (2007):
1. As responsabilidades “conhecer” estão relacionadas à
distribuição das características do sistema entre as classes
2. As responsabilidades “fazer” estão relacionadas com a
distribuição do comportamento do sistema entre as classes
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Creator (Criador)
• Problema: quem deve ser o responsável por criar instâncias de uma
determinada classe? ”
• Solução: um objeto deve ser criado por outro que o possua como parte
(agregação) ou esteja fortemente associado a ele.
• Para identificar o criador de um objeto A, verifique:
• se o objeto A é parte em um relacionamento todo/parte;
normalmente o todo é o responsável pela criação de A.
• se algum outro objeto tem uma associação de um para muitos, onde
A é o lado muitos.
• se o objeto A está associado ao objeto de controle.
• se alguma classe tem dados necessários à inicialização de A.
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
• Quem deve criar objetos ItemVenda?
• Quem deve criar objetos Pagamento?
• Quem deve criar objetos Venda?
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo 2
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Low Coupling (Acoplamento Fraco)
• O acoplamento é uma medida de quão fortemente uma classe está
conectada a outras classes, tem conhecimento das mesmas ou depende
delas.
• Uma classe com baixo (fraco) acoplamento não depende de muitas outras.
• Uma classe com acoplamento forte é:
• �mais difícil de compreender isoladamente
• �mais difícil de reutilizar (seu uso depende da reutilização
• das outras classes da qual ela depende)
• sensível a mudanças nas classes associadas.
• Sempre que possível, evite que o envio de mensagens implique na criação
de associações redundantes no modelo.
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Expert (Especialista da informação)
• É o padrão mais usado para atribuir responsabilidades
• Problema: dado um comportamento (responsabilidade) a qual classe
essa responsabilidade deve ser alocada?
• Solução: atribuir essa responsabilidade ao especialista da informação
– a classe que tem a informação necessária para satisfazer a
responsabilidade.
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
• Caso de uso registrar venda, foi identificada a responsabilidade do
sistema gerar o total da venda.
• Que classe deve assumir essa responsabilidade?
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Expert (Especialista da informação)
• A informação necessária para uma tarefa computacional frequentemente
está “espalhada” por vários objetos.
• Portanto, há muitos experts parciais
• Exemplo: determinar o total de uma venda requer a colaboração de
3 objetos, em 3 classes diferentes.
• Neste caso mensagens são usadas para estabelecer as colaborações
• Note que, com o uso do padrão Expert o encapsulamento das classes é
mantido, já que:
• �objetos usam sua própria informação para cumprir suas
responsabilidades ou
• �enviam mensagens a seus colaboradores para obter informações
que não possuem
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Polymorphism (Polimorfismo)
• Problema:
o Como tratar alternativas em função do tipo da classe?
 O uso de ifs aninhados ou switch-case para selecionar
comportamento em função do tipo de classe espalha-se por
todo o código, dificultando a Manutenção
• Solução:
o Seleção do comportamento desejado através domecanismo de
polimorfismo
o Utilização de polimorfismo aplicado ao conceito de interfaces
para permitir a substituição de componentes
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
If(tipo_pagamento == CARTAO_CREDITO)
autorizar_credito()
Else
If(tipo_pagamento == CARTAO_DEBITO)
autorizar_debito()
Else
If(tipo_pagamento == CHEQUE)
autorizar_cheque()
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
High Cohesion (Coesão alta)
• Problema:
o Como manter a complexidade sob controle?
o As classes são difíceis de compreender
o As classes são difíceis de reutilizar
o As classes são difíceis de manter
o As classes são frágeis, sendo afetadas por praticamente todas as
modificações
• Solução:
o Atribuir responsabilidade de forma que as classes não fiquem
sobrecarregadas, e que as suas atribuições sejam relacionadas
o O padrão High Cohesion também deve ser visto como um padrão de
avaliação de padrões
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Controller(Controlador)
• Problema:
• Quem deveria ser responsável por tratar um evento do sistema?
• Solução: atribuir a responsabilidade do tratamento de um evento do
sistema a uma classe que representa uma das seguintes escolhas:
o Representa o “sistema” todo (controlador fachada)
o Representa um tratador oficial de todos os eventos de sistema
de um caso de uso (controlador de caso de uso)
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Pure Fabrication (Invenção Pura)
• Problema:
o Que objeto deve ter a responsabilidade, quando não se quer
violar a Alta Coesão e o Baixo Acoplamento, mas as soluções
oferecidas por Expert não são adequadas?
o Atribuir responsabilidades apenas para classes do domínio
conceitual pode levar à situações de maior acoplamento e menos
coesão.
• Solução:
o Atribuir um conjunto altamente coesivo de responsabilidades a
uma classe artificial que não representa um conceito do domínio
do problema.
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
• Apesar de Sale ser a candidata lógica para ser a Expert, para salvar a
si mesma em um banco de dados, isto levaria o projeto a ter baixo
acoplamento, alta coesão e baixo reuso;
• Uma solução seria criar uma classe responsável somente por isto:
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Indireção
• Problema:
o A quem devemos atribuir a responsabilidade, evitando o
acoplamento direto entre dois ou mais objetos?
o Como desacoplar objetos apoiando o Acoplamento Baixo e
maximizando o potencial de reuso?
• Solução:
o Atribua a responsabilidade a um objeto intermediário para
mediar as mensagens entre outros componentes ou serviços,
para que não sejam diretamente acoplados;
o O objeto intermediário cria uma camada de indireção entre os
dois componentes que não mais dependam um do outro: Ambos
dependem da indireção.
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
• O objeto AdaptadorMestreDosImpostos atua como intermediário para
o calculador externo de imposto.
• Por meio de Polimorfismo, ele fornece uma interface consistente
• com os objetos internos e ocultam as variações nas APIs externas
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
• O exemplo de Invenção Pura de desacoplar a Venda dos serviços de
Banco de Dados através da classe ArmazenamentoPersistente
• É também um exemplo de atribuir responsabilidade para apoiar a
Indireção.
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Variações protegidas
• Problema:
o Como projetar objetos, subsistemas e sistemas para que as
variações ou instabilidades nesses elementos não tenham um
impacto indesejável nos outros elementos?
• Solução:
o Identificar pontos de variação ou instabilidade potenciais;
o Atribuir responsabilidades para criar uma interface estável em
volta desses pontos;
o Encapsulamento, interfaces, polimorfismo, indireção e padrões;
Máquinas virtuais e brokers são motivados por este princípio;
o Evitar enviar mensagens a objetos muito distantes.
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
• A solução com Polimorfismo para os calculadores de impostos externos 
é um exemplo de Variações Protegidas
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Variações protegidas
• O ponto de instabilidade (variação) são as diferentes interfaces de 
calculadores externos
• Acrescentando um nível de Indireção, uma Interface e usando o 
Polimorfismo com várias implementações de 
IAdaptadorDeCalculadorDeImposto
o Protegemos o sistema a partir de variações nas APIs externas.
o Objetos internos colaboram com uma interface estável
o Várias implementações do Adaptador ocultam as variações para 
os sistemas externos.
Revisão – AULA RAV2
PADRÕES DE PROJETO DE SOFTWARE
Bibliografia
Utilizando UML e Padrões: uma introdução à análise e ao
projeto orientados a objetos - 3ª Edição
Autor: Larman, Craig
Padrões de Projeto: soluções reutilizáveis de software
orientado a objetos
Autor: Gamma, Erich ... [et al]
	revisaoav1
	Número do slide 1
	Número do slide 2
	Número do slide 3
	Número do slide 4
	Número do slide 5
	Número do slide 6
	Número do slide 7
	Número do slide 8
	Número do slide 9
	Número do slide 10
	Número do slide 11
	Número do slide 12
	Número do slide 13
	Número do slide 14
	Número do slide 15
	Número do slide 16
	Número do slide 17
	Número do slide 18
	Número do slide 19
	Número do slide 20
	Número do slide 21
	Número do slide 22
	Número do slide 23
	Número do slide 24
	Número do slide 25
	Número do slide 26
	Número do slide 27
	Número do slide 28
	Número do slide 29
	Número do slide 30
	Número do slide 31
	Número do slide 32
	Número do slide 33
	Número do slide 34
	Número do slide 35
	Número do slide 36
	Número do slide 37
	Número do slide 38
	Número do slide 39
	Número do slide 40
	Número do slide 41
	Número do slide 42
	Número do slide 43
	Número do slide 44
	Número do slide 45
	Número do slide 46
	Número do slide 47
	Número do slide 48
	Número do slide 49
	Número do slide 50
	Número do slide 51
	Número do slide 52
	Número do slide 53
	Número do slide 54
	Número do slide 55
	Número do slide 56
	Número do slide 57
	Número do slide 58
	Número do slide 59
	Número do slide 60
	Número do slide 61
	Número do slide 62
	Número do slide 63
	Número do slide 64
	Número do slide 65
	Número do slide 66
	Número do slide 67
	Número do slide 68
	Número do slide 69
	Número do slide 70
	Número do slide 71
	Número do slide 72
	Número do slide 73
	Número do slide 74
	Número do slide 75
	Número do slide 76
	Número do slide 77
	Número do slide 78
	Número do slide 79
	Número do slide 80
	Número do slide 81
	Número do slide 82
	Número do slide 83
	Número do slide 84
	Número do slide 85
	Número do slide 86
	Número do slide 87
	Número do slide 88
	Número do slide 89
	Número do slide 90
	Número do slide 91
	Número do slide 92
	Número do slide 93
	Número do slide 94
	Número do slide 95
	Número do slide 96
	Número do slide 97
	Número do slide 98
	Número do slide 99
	Número do slide 100
	Número do slide 101
	Número do slide 102
	Número do slide 103
	Número do slide 104
	Número do slide 105
	Número do slide 106
	Número do slide 107
	Número do slide 108
	Número do slide 109
	Número do slide 110
	Número do slide 111
	Número do slide 112
	Número do slide 113
	Número do slide 114
	Número do slide 115
	Número do slide 116
	Número do slide 117
	Número do slide 118
	Número do slide 119
	Número do slide 120
	Número do slide 121
	Número do slide 122
	Número do slide 123
	Número do slide 124
	Número do slide 125
	Número do slide 126
	Número do slide 127
	Número do slide 128
	Número do slide 129
	Número do slide 130
	Número do slide 131
	Número do slide 132
	Número do slide 133
	Número do slide 134
	Número do slide 135
	Número do