Oswaldo Borges Peres PADRÕES DE PROJETO Aula RAV1

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

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. 
• Desvantagem:
◦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
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 das muitas 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
Builder : é 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. 
Sub [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
Produto : é 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
Nessa 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: 
Normal: não aceita alterações na ordem de produção, se ela não atende aos requisitos mínimos. 
Flexí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. 
Apenas se deve notar que não cabem ajustes aos parâmetros data (que deve ser posterior à atual) e ao modelo (que deve ser um dos quatro modelos: Gol, Golf, Vectra ou Ômega): se não estiverem de acordo, a ordem não será aceita de maneira alguma
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
Nessa 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: 
Normal: não aceita alterações na ordem de produção, se ela não atende aos requisitos mínimos. 
Flexí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. 
Apenas se deve notar que não cabem ajustes aos parâmetros data (que deve ser posterior à atual) e ao modelo (que deve ser um dos quatro modelos: Gol, Golf, Vectra ou Ômega): se não estiverem de acordo, a ordem não será aceita de maneira alguma
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 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. 
A 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
OPBuilder é 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
A 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. 
Uma 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
Entretanto, 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]. 
Ainda, 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
Para 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). 
Nesse 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
Alé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
A ú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
Assim, 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
A 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. 
Selecionadas 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
A 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
Prototype 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
Essas 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” pode ter 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
Acesso controlado à instância única; 
O Singleton tem controle sobre como e quando clientes acessam a instância; 
Espaço de nomes reduzido; 
O Singleton é melhor que variáveis globais, já que as "globais" podem ser encapsuladas na instância única, deixando um único nome externo visível; 
Permite refinamento de operações e de representação; 
Várias classes Singleton (relacionadas ou não via herança) podem obedecer a mesma interface, permitindo que um Singleton particular seja escolhido para trabalhar com uma determinada aplicação em tempo de execução; 
Mais flexível que métodos estáticos;
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
O 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. 
Se 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
A 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
Pelo 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. 
Atravé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
A 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 Adaptador para 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
Vantagens
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
Desvantagens
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
Sistema quer utilizar objeto real...
Mas ele não está disponível (remoto, inaccessível, ...)
Soluçã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
Oferecer uma interface única para um conjunto de interfaces de um subsistema. 
Definir uma interface de nível mais elevado que torna o subsistema mais fácil de usar [Silva, 2005]. 
Reduzir 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
Uma 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]. 
Existem 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 [Junior, 2004], como ilustrado na Figura 1. 
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?
Criação de interfaces mais simples para um ou mais subsistemas complexos.
Redução de dependência entre o cliente e as classes existentes nos subsistemas, ocasionando a redução da coesão do sistema
Criaçã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
Protege os clientes da complexidade dos componentes do subsistema; 
Promove acoplamento fraco entre o subsistema e seus clientes; 
Reduz dependências de compilação, possivelmente complexas ou circulares; 
Facilita a portabilidade do sistema [Junior, 2004]; 
Reduz 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]; 
Não evita que aplicações possam acessar diretamente as subclasses do sistema, se assim o desejarem [Junior, 2004]; 
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
Quando 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)
Quando 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 separar objetos mutáveis de imutáveis
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
Fornece 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
Alimentador : define a interface para tratar as solicitações e implementa a referência ao sucessor (opcional). 
AlimentadorConcretoA, ..., 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. 
Cliente : Inicia a solicitação para um objeto AlimentadorConcreto da cadeia. 
Requisição : As instâncias de
Requisição é que iram transportar as informações para os alimentadores executarem algo. 
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Vantagens
Evita 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.
Encadeia os objetos receptores e passa a requisição ao longo dessa cadeia até que um objeto possa manipulá-lo.
Reduz a vinculação.
Adiciona flexibilidade.
Permite que um conjunto de classses atue como uma classe; eventos produzidos em uma classe podem ser enviados para outras classes dentro da composição.
PADRÕES ESTRUTURAIS GOF – AULA RAV1
PADRÕES DE PROJETO DE SOFTWARE
Exemplo
No 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. 
As 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
Como 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. 
Neste 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 algum. 
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]
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*