© 2001 Jaelson CastroPadrões de Projeto 1 Padrões de Projeto.
Transcript of © 2001 Jaelson CastroPadrões de Projeto 1 Padrões de Projeto.
© 2001 Jaelson Castro Padrões de Projeto 1
Padrões de Projeto
© 2003 Jaelson Castro
Padrões de Projeto 2
Objetivos
O que é entendido pelo termo padrão Que tipos de padrões têm sido
identificados no desenvolvimento de software
Como aplicar padrões de projeto durante o desenvolvimento de software
Os benefícios e dificuldades que podem surgir quando usamos padrões
© 2003 Jaelson Castro
Padrões de Projeto 3
Padrões Projetar software OO bom e reusável é difícil.
Mistura de específico+ genérico Impossível acertar da primeira vez
Projetistas experientes usam soluções com as quais já trabalharam no passado.
Padrões de projeto Sistematicamente
nomes, explicações, e avaliações
© 2003 Jaelson Castro
Padrões de Projeto 4
Genesis Christopher Alexander, et. al. 1977
“Cada padrão descreve um problema que ocorre sempre em nosso ambiente, e então descreve o núcleo de uma solução para o problema, de que maneira você pode usar esta solução um milhão de vezes mais, sem fazê-la do mesmo jeito duas vezes.”
Apropriada para prédios e pontes. Durante a última década, uma “comunidade de
padrões” tem sido desenvolvida.
© 2003 Jaelson Castro
Padrões de Projeto 5
Genesis “Um padrão é a abstração de uma forma concreta que
ocorre muitas vezes em contextos não arbitrários específicos.” Riehle and Zullighoven, 1996
“Cada padrão é uma regra de três partes, que expressa uma relação entre um certo contexto, um certo sistema de forças que ocorre repetidamente naquele contexto, e uma certa configuração de software que permite que estas forças resolva-os” Gabriel 1996.
“Resolve um problema. É um conceito provado. A solução não é óbvia. Descreve um relacionamento. Os padrões têm um componente humano significativo.” Coplien 1996.
© 2003 Jaelson Castro
Padrões de Projeto 6
Características dos Padrões de Software
Algo comprovado que captura, comunica os conhecimentos das melhores práticas.
A solução não é óbvia. Descoberto, não inventado. O padrão tem um componente
humano importante (ex. qualidades estéticas nos padrões de Alexander)
© 2003 Jaelson Castro
Padrões de Projeto 7
Anti-Padrões
Anti-padrões é uma maneira de documentar soluções recorrentes de soluções que não tiveram sucesso
Pode também incluir soluções re-trabalhadas que sejam efetivas.
© 2003 Jaelson Castro
Padrões de Projeto 8
Padrões Padrões de Análise:
Descreve grupos de conceitos que representam construções comuns na modelagem do domínio. Estes padrões podem ser aplicáveis em um domínio ou em muitos.
Padrões de Arquitetura: Descreve a estrutura e o relacionamento da maioria dos
componentes de um sistema de software Padrões de Projeto:
Identifica as relações internas entre um grupo de componentes de software e descreve suas responsabilidades, colaborações e relações estruturais.
Idiomas Descreve como implementar aspectos específicos de um
sistema de software numa dada linguagem de programação
© 2003 Jaelson Castro
Padrões de Projeto 9
Frameworks
Sistemas de software parcialmente completos podem ter como alvo um tipo específico de aplicação
Um sistema de aplicação apropriado para uma organização pode ser desenvolvido a partir de um framework para completar os elementos não concluídos e adicionar elementos específicos da aplicação
© 2003 Jaelson Castro
Padrões de Projeto 10
Diferenças entre os Padrões de Projeto e Frameworks
Padrões são mais abstratos e genéricos que frameworks.
Diferente de um framework, um padrão não é diretamente implementado num ambiente de software específico.
Um framework pode ser escrito em linguagens de programação e não apenas estudado, mas executado e reusado diretamente.
Ao contrário, padrões são implementados cada vez que são usados
Padrões são mais primitivos que frameworks. Um framework típico contém vários padrões, mas o inverso nunca é verdade.
© 2003 Jaelson Castro
Padrões de Projeto 11
Catálogos e Linguagens 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.
Os padrões numa linguagem de padrões estão mais relacionados, e trabalham juntos para solucionar problemas num domínio específico um conjunto de padrões que todos trabalham
juntos para solucionar um grande problema. Ex: linguagem de padrões para integridade de
informações (Cunningham95)
© 2003 Jaelson Castro
Padrões de Projeto 12
Princípios Presentes nos Padrões
Abstração Encapsulamento Proteção de informação Modularização Separação de conteúdos Acoplamento e coesão Suficiência, completude e primitividade Separação entre política e implementação Único ponto de referência Dividir para conquistar
© 2003 Jaelson Castro
Padrões de Projeto 13
Padrões e requisitos não-funcionais
Padrões podem abordar as características descritas através de requisitos não funcionais: Modificabilidade Interoperabilidade Eficiência Confiabilidade Testabilidade Reusabilidade
© 2003 Jaelson Castro
Padrões de Projeto 14
Template para Documentação de um Padrão
Elementos Mínimos:
Nome do Padrão: Deve ser facilmente lembrado, reflete o conteúdo do padrão.
Problema: Uma descrição do problema que pode ser escrito em forma de pergunta.
Contexto: Descreve o contexto do problema. As circunstâncias ou pré-condições sob as quais o problema pode ocorrer.
Forças: As restrições ou características que devem ser seguidas pela solução. As forças podem interagir e ter conflitos umas com as outras.
Solução: Deve ser direta e precisa.
© 2003 Jaelson Castro
Padrões de Projeto 15
Um exemplo A razão que justifica a solução
escolhida Padrão relacionado Uso conhecido do padrão Lista de outros nomes para o padrão Amostra de código do programa
Template de padrão: Outros Elementos
© 2003 Jaelson Castro
Padrões de Projeto 16
Não há nada como um template perfeito.
Considere Porque ter um ‘Estilo da Empresa’? Quem usará os padrões documentados? Como eles serão usados? Qual a composição de texto, diagramas e
código? Como prevenir erros de uso?
Problemas com padrões de documentação
© 2003 Jaelson Castro
Padrões de Projeto 17
Padrões de Projeto
Padrões de Projeto foram introduzidos para a comunidade OO através de Gamma E., et al, Design Patterns, Addison-
Wesley, 1994 Eles categorizaram (23) padrões em
três tipos: Criação (5) Estrutural (7) Comportamental (11)
© 2003 Jaelson Castro
Padrões de Projeto 18
Escopo Classe
Relacionamentos entre classes e suas subclasses
Não precisa executar nenhum código para determinar o uso dos padrões
Estático, fixo em tempo de compilação Objeto
Confia em ponteiros de objetos. Pode ser alterado em tempo de execução,
são mais dinâmicos.
© 2003 Jaelson Castro
Padrões de Projeto 19
Propósito dos Padrões Criação
Relacionado com o processo de criação do objeto
Estrutural Relacionado com os relacionamentos entre
classes e objetos Oferece caminhos efetivos para usar conceitos
OO como herança, agregação e composição Comportamental
Relacionado com os caminhos para que objetos e classes distribuam a responsabilidade para realizar a mesma tarefa.
© 2003 Jaelson Castro
Padrões de Projeto 20
Padrão criação Abstraem o processo de criação de
instâncias (objetos), oferecendo flexibilidade no que é criado, por quem, como e quando.
© 2003 Jaelson Castro
Padrões de Projeto 21
Alguns Exemplos Padrão criação
Singleton Abstractfactory Builder FactoryMethod Prototype
© 2003 Jaelson Castro
Padrões de Projeto 22
Padrão de Criação: Singleton Nome: Singleton (Único) Problema: Como pode ser construída
uma classe que só pode ter uma única instância e que pode ser acessada globalmente dentro da aplicação?
Contexto: Em algumas aplicações uma classe deve ter exatamente uma instância.
© 2003 Jaelson Castro
Padrões de Projeto 23
Padrão de Criação: Singleton
Forças: Uma abordagem para tornar um objeto
acessível globalmente é colocar a variável global, mas isto viola o encapsulamento.
Outra abordagem é não criar uma instância de objeto em todo lugar, mas usar operações e atributos da classe (chamados `static´ em C++ e Java), mas isto limita a extensibilidade do modelo desde que a redefinição polimórfica das operações da classe não é possível em todos os ambientes de desenvolvimento (por exemplo C++)
© 2003 Jaelson Castro
Padrões de Projeto 24
Padrão de Criação: Singleton Solução:
Criar uma classe com uma operação de escopo de classe (ou estática, ex: Java, C++) getInstance(), que:
Quando a classe é acessada pela primeira vez, a instância do objeto é criada e retornada para o cliente.
Nos acessos subseqüentes de getInstance() nenhuma instância adicional é criada, mas a identidade do objeto existente é retornado.
© 2003 Jaelson Castro
Padrões de Projeto 25
Padrão de Criação: Singleton Estrutura:
Singleton
static uniqueInstancesingletonData
getInstance()singletonOperation()getSingletonData()
return unique instance
© 2003 Jaelson Castro
Padrões de Projeto 26
Padrão de Criação: Singleton Vantagens:
Oferece acesso controlado a única instância do objeto, pois a classe Singleton encapsula a instância.
O espaço de nome não é necessariamente estendido com variáveis globais.
A classe Singleton pode ter subclasses. Pode-se determinar que subclasses são instanciadas quando a classe Singleton é acessada pela primeira vez.
Uma variação do padrão pode ser usada para criar um número específico de instâncias, se for requerido.
© 2003 Jaelson Castro
Padrões de Projeto 27
Padrão Singleton – Exemplo Agate O sistema de gerenciamento de
campanhas Agate precisa guardar informações a respeito da empresa.
Estas informações só devem ser guardadas em um lugar dentro da aplicação, mas serão usadas por diferentes objetos.
© 2003 Jaelson Castro
Padrões de Projeto 28
Padrão Singleton – Exemplo Agate
Quando um objeto cliente precisa acessar o objeto Company pode enviar a mensagem getCompanyInstance() e receber o identificador do objeto na resposta.
O objeto cliente pode então enviar uma mensagem getCompanydetails() para o objeto Company
© 2003 Jaelson Castro
Padrões de Projeto 29
Padrão Singleton – Exemplo Agate Mas ela opera como uma empresa
separada em cada país diferentes detalhes registrados da
empresa para cada país
© 2003 Jaelson Castro
Padrões de Projeto 30
Padrão Singleton –Agate
A classe Company só é instanciada uma vez. Ela é acessível globalmente.
Diferentes subclasses de Company que são instanciadas quando necessário, dependendo das circunstâncias em tempo de execução.
© 2003 Jaelson Castro
Padrões de Projeto 31
Padrão AbstractFactory (kit) Meta
Provê uma interface para criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas.
Motivação Muitas vezes um programa necessita criar
famílias inteiras de objetos que se relacionam entre si
© 2003 Jaelson Castro
Padrões de Projeto 32
AbstractFactory Estrutura do Padrão
AbstractFactory
createProductA()createProductB()
ConcreteFactory1createProductA()createProductB()
ConcreteFactory2createProductA()createProductB()
abstractProductA
abstractProductB
client
productA2
productB2
productA1
productB1MotifWidgetFactory
Widget Factory
PMWidgetFactory
Window
ScrollBar
© 2003 Jaelson Castro
Padrões de Projeto 33
AbstractFactory Participantes
AbstractFactory Declara uma interface para operações que criam objetos
(produtos) abstratos ConcreteFactory
Implementa a operações para criar objetos (produtos) concretos
AbstractProduct Declara uma interface para um tipo de objeto (produto)
ConcreteProduct Define um objeto (produto) para ser criado pela
ConcreteFactory correspondente Client
Usa apenas interfaces declaradas pela AbstractFactory e AbstractProduct
© 2003 Jaelson Castro
Padrões de Projeto 34
AbstractFactoryAplicabilidade
Use o Padrão AbstractFactory quando: Um sistema deve ser independente de como seus
produtos são criados, compostos e representados Um sistema deve ser configurado com uma entre
múltiplas famílias de produtos Uma família de produtos foi projetada para
trabalhar em conjunto e você necessita garantir o cumprimento destas restrições
Você quer fornecer uma biblioteca de produtos (biblioteca ou framework), mas quer revelar apenas as interfaces dos produtos, mas não suas implementações
© 2003 Jaelson Castro
Padrões de Projeto 35
AbstractFactoryColaborações
Normalmente uma única instância de uma fábrica concreta é criada em run-time Esta fábrica concreta cria objetos (produtos)
com uma implementação particular Para criar produtos diferentes, clientes
devem usar fábricas concretas diferentes A AbstractFactory transfere a
criação de objetos para as suas subclasses (ConcreteFactory)
© 2003 Jaelson Castro
Padrões de Projeto 36
AbstractFactoryConseqüências
Isola Fábricas Concretas Facilita a Substituição de Famílias de
Produtos Promove Consistência Entre Produtos Suporte a Novos Tipos de Produtos é
difícil
© 2003 Jaelson Castro
Padrões de Projeto 37
Padrão Builder Intenção
Separar construção da implementação de um objeto complexo, de modo que o mesmo processo de construção possa criar várias representações diferentes
Motivação Um programa muitas vezes necessita ler um formato
de documento (fonte) e convertê-lo em vários outros formatos diferentes (objeto).
Se os formatos (objeto) não são definidos a priori, é possível configurar o programa com um conversor (builder) que pode ser especializado em diferentes formatos e operações de conversão
© 2003 Jaelson Castro
Padrões de Projeto 38
Padrão BuilderEstrutura e Participantes
Director
construct()
builder
for all objects in structure { builder.buildPart();}
AbstractBuilder
buildPart()
Product1
ConcreteBuilder2
buildPart()getResult()
Product2
ConcreteBuilde3r
buildPart()getResult()
Product3
builders
ConcreteBuilder1
buildPart()getResult()
TextConverter
ASCIIConverter
TeXConverter
WordConverter
ASCIIText TeXText WordText
RTFReader
© 2003 Jaelson Castro
Padrões de Projeto 39
Padrão BuilderColaborações
aBuilder = new ConcreteBuilder()
aClient aBuilderaDirector
aDirector = new Director(aBuilder)
aDirector.construct()
aBuilder.buildPartA()
aBuilder.buildPartB()
aBuilder.buildPartC()
aBuilder.getResult()
© 2003 Jaelson Castro
Padrões de Projeto 40
Padrão BuilderAplicabilidade e Conseqüências
Use o Padrão Builder quando O algoritmo para criar um objeto complexo deve ser
independente das partes que constróem o objeto e de como elas são montadas
O processo de construção necessita fornecer representações diferentes para o objeto que é construído
Conseqüências do Padrão Builder Permite variar a representação interna de um
produto Isola os códigos de construção e representação Permite controle fino sobre o processo de construção
© 2003 Jaelson Castro
Padrões de Projeto 41
Padrão FactoryMethod Intenção
Definir uma interface para criação de um objeto, mas deixar que subclasses decidam as classes dos objetos a instanciar
Motivação Frameworks para criação de aplicações que
trabalham sobre documentos necessitam ser refinados para definir exatamente qual a aplicação a ser criada, e qual o tipo de documento sobre a qual ela vai trabalhar
© 2003 Jaelson Castro
Padrões de Projeto 42
Padrão FactoryMethodEstrutura e Participantes
...Product p = factoryMethod();...
Creator
factoryMethod()Product
ConcreteCreator
factoryMethod()
ConcreteProduct
operation()
return new ConcreteProduct();
Document
MyDocument
Application
MyApplication
© 2003 Jaelson Castro
Padrões de Projeto 43
Padrão FactoryMethodAplicabilidade e Conseqüências
Use o Padrão FactoryMethod quando: Uma classe não pode antecipar qual a classe do objeto que
ela deve criar. Uma classe quer que suas subclasses definam o objeto que
elas criam Classes delegam responsabilidades para uma entre muitas
subclasses auxiliares, e você quer limitar o conhecimento de qual subclasse auxiliar recebeu a delegação.
Conseqüências Eliminam a necessidade de ligar classes específicas ao
código Clientes necessitam criar subclasses sempre que precisam
criar produtos Conectam hierarquias de classes paralelas
© 2003 Jaelson Castro
Padrões de Projeto 44
Padrão Prototype Intenção
Especificar os tipos de objetos a criar usando uma instância prototípica, e criar novos objetos através da clonagem deste protótipo
Motivação Você deseja parametrizar o funcionamento
de uma parte da aplicação mas não quer usar herança, pois a quantidade de subclasses diferentes seria muito grande
© 2003 Jaelson Castro
Padrões de Projeto 45
Padrão PrototypeParticipantes e Colaboradores
...p = prototype.clone();...
Cliente Prototype
clone()operation()
ConcretePrototype1
clone()
ConcretePrototype2
clone()
prototypeFerramentaGráfica Gráfico
Pauta Breve
© 2003 Jaelson Castro
Padrões de Projeto 46
Padrão PrototypeAplicabilidade
Use o Padrão Prototype Quando: Um sistema deve ser independente de
como seus produtos são criados, compostos e representados, e
Quando as classes a instanciar são especificadas em run-time, por exemplo, através de carga dinâmica, ou;
Quando instâncias de uma classe podem ter apenas poucas combinações de estados. Fica então mais conveniente clonar objetos em vez de construir novos objetos
© 2003 Jaelson Castro
Padrões de Projeto 47
Padrão PrototypeConseqüências
Reduz o número de classes que os clientes conhecem
Permitem Que o cliente trabalhe com classes específicas de uma
aplicação, sem necessidade de recompilação Adicionar e remover produtos em run-time Especificar novos objetos através da variação de valores Especificar novos objetos através de variação na estrutura Reduzir o número de subclasses Configuração dinâmica de aplicações
Cada subclasse deve implementar o método clone()
© 2003 Jaelson Castro
Padrões de Projeto 48
Padrão Estrutural
Tratam de compor classes e objetos para formar estruturas grandes e complexas
© 2003 Jaelson Castro
Padrões de Projeto 49
Padrão Estrutural:Exemplo
Composite Adapter Bridge Decorator Facade Flyweight Proxy
© 2003 Jaelson Castro
Padrões de Projeto 50
Padrão Estrutural: Composite Nome: Composto Problema: Existe um requisito para
representar hierarquias todo-parte, então ambos objetos (todo e parte) oferecem a mesma interface para objetos do cliente.
Contexto: Numa aplicação tanto o objeto que contém quanto o que é componente são requeridos para oferecer o mesmo comportamento.
Objetos cliente devem ser capazes de tratar objetos compostos ou componentes do mesmo jeito (ex.: graphical drawing package)
© 2003 Jaelson Castro
Padrões de Projeto 51
Padrão Estrutural: Composite Forças:
O requisito que os objetos, tanto composto como componente, ofereçam a mesma interface, sugere que eles pertençam a mesma hierarquia de herança.
Isto permite que operações sejam herdadas e redefinidas com a mesma assinatura (polimorfismo).
A necessidade de representar hierarquias todo-parte indica a necessidade para uma estrutura de agregação
© 2003 Jaelson Castro
Padrões de Projeto 52
Padrão Estrutural: Composite
Solução : Combinar hierarquias de herança e agregação.
© 2003 Jaelson Castro
Padrões de Projeto 53
Padrão Estrutural: Composite
Solução: Ambas subclasses, Leaf e Composite, têm
uma operação redefinida usando o polimorfismo anOperation().
Na classe Composite esta operação redefinida invoca a operação relevante a partir de seus componentes usando um loop.
A subclasse Composite também tem operações adicionais para gerenciar a hierarquia de agregação, então os componentes podem ser adicionados ou removidos.
© 2003 Jaelson Castro
Padrões de Projeto 54
Padrão Composite : Graphical drawing package
Graphic
drawgetChildremoveGraphicaddGraphic
CompositeGraphic
drawgetChildremoveGraphicaddGraphic
Line
draw
Rectangle
draw
Circle
draw
Client0..*
© 2003 Jaelson Castro
Padrões de Projeto 55
Padrão Composite : Agate
© 2003 Jaelson Castro
Padrões de Projeto 56
Padrão Adapter Intenção
Converter a interface de uma classe em outra interface que clientes possam utilizar. Compatibiliza classes, permitindo que trabalhem em conjunto.
Motivação Algumas vezes uma classe (de um toolkit) não é
reusável somente porque sua interface não é compatível com a interface de uma aplicação de um domínio específico.
A solução é criar um objeto adaptador, que encapsule e filtre as especificidades da classe adaptada, fornecendo uma interface que a aplicação espera utilizar
© 2003 Jaelson Castro
Padrões de Projeto 57
specificRequest()
Client Target
request()
Adapter
request()
Adaptee
specificRequest()
Padrão (Class)AdapterEstrutura e Participantes
Usando Herança Múltipla
© 2003 Jaelson Castro
Padrões de Projeto 58
adaptee.specificRequest();
Client Target
request()
Adapter
request()
Adaptee
specificRequest()
Padrão (Object)AdapterEstrutura e Participantes
Usando Composição
adaptee
DrawingEditor
Shape
TextShape
TextView
© 2003 Jaelson Castro
Padrões de Projeto 59
Padrão AdapterAplicabilidade
Use o Padrão Adapter quando: Você quer usar uma classe existente, e sua interface
não é compatível com uma que você criou Você quer criar uma classe reusável que coopera com
classes não relacionadas ou não previstas a priori, isto é, classes que não apresentam necessariamente a mesma interface
(Somente para ObjectAdapter) Você precisa usar várias subclasses existentes (de Adaptee), mas é impraticável adaptar as interfaces de cada uma através de herança. Um ObjectAdapter pode resolver isto adaptando abstratamente a interface da superclasse.
© 2003 Jaelson Castro
Padrões de Projeto 60
Padrão AdapterConseqüências
ClassAdapter Adapta uma classe concreta, mas NÃO SUAS
SUBCLASSES Pode sobrepor alguns comportamentos do adaptado,
visto que é uma subclasse da classe adaptada ObjectAdapter
Permite que um único Adapter trabalhe com muitos adaptados. Ou seja, o próprio Adaptee e suas subclasses.
Pode adicionar funcionalidade extra a todos os adaptados de uma só vez.
© 2003 Jaelson Castro
Padrões de Projeto 61
Padrão Bridge Intenção
Desacoplar uma abstração de sua implementação, de modo que as duas possam variar independentemente.
Motivação Quando uma abstração pode ter várias
implementações a solução usual é acomodar todas as implementações através de herança
No entanto, herança liga de forma permanente uma abstração a uma implementação
O padrão Bridge permite colocar as abstrações e suas implementações em diferentes hierarquias de classes, e permite que variem de forma independente
© 2003 Jaelson Castro
Padrões de Projeto 62
Padrão BridgeEstrutura e Colaboradores
Implementor
operationImp()
ConcreteImplementorA
operationImp()
ConcreteImplementorB
operationImp()
Abstraction
operation()
imp
imp.operationImpl();
RefinedAbstraction
Client
WindowWindowImp
IconWindowXWindowImp PMWindowImp
© 2003 Jaelson Castro
Padrões de Projeto 63
Padrão BridgeAplicabilidade
Use o Padrão Bridge Quando: Você quer evitar ligação permanente entre uma
abstração e sua implementação. Pode ser, por exemplo, quando se deseja variar a implementação em run-time
Tanto a abstração quanto a implementação devem ser extensíveis através de herança
Mudanças na implementação de uma abstração não devem ter impacto sobre o cliente
© 2003 Jaelson Castro
Padrões de Projeto 64
Padrão BridgeConseqüências
Desacoplamento entre interface e implementação
Implementação de uma abstração configurada em run-time
Eliminação de dependências de compilação Criação de camadas de abstração que podem melhor
estruturar o sistema Extensibilidade incrementada
Herança para abstração e implementação Detalhes de implementação são escondidos do
cliente
© 2003 Jaelson Castro
Padrões de Projeto 65
Padrão Decorator Intenção
Anexa dinamicamente responsabilidades adicionais a um objeto. Provê uma alternativa flexível ao uso de herança como modo de estender funcionalidade.
Motivação Algumas vezes se quer 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 um scrollbar a uma área de texto.
Uma forma de se acrescentar responsabilidades é através de herança, mas isto torna o projeto inflexível, pois a escolha da borda é definida em tempo de compilação. Neste caso o cliente não pode controlar como, onde e quando decorar o componente com uma borda.
Uma abordagem mais flexível é inserir o componente em outro objeto que adiciona a borda, um Decorator.
© 2003 Jaelson Castro
Padrões de Projeto 66
Padrão DecoratorEstrutura e ParticipantesComponent
operation()
ConcreteComponent
operation()
ConcreteDecoratorB
operation()addedBehavior()
Decoratorcomponent
operation()
ConcreteDecoratorA
operation()
addedState
super.operation();addedBehavior();
component.operation();
TextView
BorderDecorator ScrollDecorator
VisualComponent
© 2003 Jaelson Castro
Padrões de Projeto 67
Padrão DecoratorAplicabilidade
Use o padrão Decorator: Para adicionar responsabilidades a objetos
individuais de forma dinâmica e transparente, sem afetar outros objetos
Para responsabilidades que podem ser removidas Quando extensão através de herança é impraticável.
Algumas vezes uma grande quantidade de extensões independentes são possíveis e seria necessário um imenso número de subclasses para suportar cada combinação possível entre elas.
Conseqüências Mais flexibilidade que herança Evita incorporação forçada de comportamentos
desnecessários
© 2003 Jaelson Castro
Padrões de Projeto 68
Padrão Facade Intenção
Prover uma interface unificada para o conjunto de interfaces de um subsistema. Define uma interface de alto nível que faz um subsistema mais fácil de usar.
Motivação Estruturar um sistema em subsistemas contribui
para reduzir sua complexidade. A dependência entre subsistemas pode ser minimizada através do uso de um objeto Fachada, o qual provê uma interface única e uniforme para as diversas funcionalidades de um subsistema.
© 2003 Jaelson Castro
Padrões de Projeto 69
Padrão FacadeEstrutura e Participantes
Facadesubsystem classes
Client Compilador
Parser
Scanner
Token
© 2003 Jaelson Castro
Padrões de Projeto 70
Padrão FacadeAplicabilidade
Use o Padrão Facade quando: Você quer prover uma interface simplificada para
um subsistema complexo. Um Facade pode prover uma visão simples e default do subsistema, suficiente para a maioria dos clientes
Existem muitas dependências entre clientes e classes da implementação. O Facade reduz esta dependência e promove independência e portabilidade
Você quer criar sistemas em camadas. Um Facade provê o ponto de entrada para cada camada (nível) do subsistema.
© 2003 Jaelson Castro
Padrões de Projeto 71
Padrão FacadeConseqüências
Protege os clientes dos componentes do subsistema
Promove acoplamento fraco entre o subsistema e seus clientes Reduz dependências de compilação Facilita a portabilidade do sistema
Não evita que aplicações possam acessar diretamente as subclasses do sistema, se assim o desejarem.
© 2003 Jaelson Castro
Padrões de Projeto 72
Padrão Flyweight Intenção
Usar compartilhamento para suportar uma grande quantidade de objetos de baixa granularidade de forma eficiente.
Motivação Algumas aplicações podem se beneficiar do uso de objetos
em seu projeto, mas uma implementação ingênua pode tornar este uso proibitivamente dispendioso (principalmente o consumo de memória)
Um Flyweight é um objeto compartilhado que pode ser usado em múltiplos contextos simultaneamente, porque possui um estado intrínseco (comum a todos os contextos) e se utiliza de vários estados extrínsecos (particulares a cada contexto onde o Flyweight é usado).
Clientes são responsáveis por passar o estado extrínseco ao Flyweight quando vão utilizá-lo.
© 2003 Jaelson Castro
Padrões de Projeto 73
Padrão FlyweightEstrutura e Colaboradores
ConcreteFlyweight
Operation(extrinsincState)
FlyweightFactory
getFlyweight(key)
imp
If (flyweight[key] exists) { return existing flyweight} else { create new flyweight; add it to pool of flyweights; return the new flyweight;}
Client
UnsharedConcreteFlyweight
Operation(extrinsincState)
Flyweight
Operation(extrinsincState)
intrinsincState allState
Glyph
Character Row, Collumn
© 2003 Jaelson Castro
Padrões de Projeto 74
Padrão FlyweightAplicabilidade
Use o Padrão Flyweight quando TODAS as condições abaixo forem verdadeiras:
A aplicação usa uma grande quantidade de objetos Custos de armazenamento são altos, por causa da imensa
quantidade de objetos Parte considerável do estado do objeto pode se tornar
extrínseco Uma vez que o estado extrínseco é removido, muitos
agrupamentos de objetos podem ser substituídos por uma quantidade consideravelmente menor de objetos compartilhados
A aplicação não depende de identidade de objetos. Visto que flyweights podem ser compartilhados, testes de identidade irão retornar true para objetos conceitualmente distintos.
© 2003 Jaelson Castro
Padrões de Projeto 75
Padrão FlyweightConseqüências
Custos de run-time associados com transferência, busca e/ou computação do estado extrínseco. Tais custos são compensados pela economia em uso de memória, à medida que mais flyweights são criados.
Redução de consumo de memória é função de: redução do número total de instâncias resultantes
do compartilhamento quantidade de estado intrínseco por objeto Se o estado extrínseco é armazenado ou computado
© 2003 Jaelson Castro
Padrões de Projeto 76
Padrão Proxy Intenção
Prover um representante para outro objeto de modo a controlar o acesso a este
Motivação Várias razões para controlar acesso a um objeto,
como por exemplo: deferir o custo de criação e inicialização para o
momento de uso (objetos sob demanda); Prover um representante local para um objeto remoto; Proteger o objeto original.
© 2003 Jaelson Castro
Padrões de Projeto 77
Padrão Proxy Estrutura e Colaboradores
RealSubject
request()...
Client
Proxy
request()...
Subject
request()
realSubject.request();
Graphic
ImageImageProxy
© 2003 Jaelson Castro
Padrões de Projeto 79
Padrão Proxy Conseqüências
Acrescenta um nível de indireção adicional
© 2003 Jaelson Castro
Padrões de Projeto 80
Padrão Comportamental
Preocupam-se com algoritmos e a atribuição de responsabilidades entre objetos. Descrevem padrões de comunicação entre os objetos.
© 2003 Jaelson Castro
Padrões de Projeto 81
Alguns Exemplos De Objeto
Baseados no uso de composição State, Chain of Responsability, Command,
Mediator, Observer, Strategy, Visitor, Iterator, Memento
De Classe Baseados no uso de herança Template Method Interpreter
© 2003 Jaelson Castro
Padrões de Projeto 82
Padrão Comportamental: State Nome: State Problema: Um objeto exibe um
comportamento diferente quando seu estado interno muda, fazendo o objeto parecer ter mudado a classe em tempo de execução.
Contexto: Ema algumas aplicações um objeto pode ter o comportamento complexo que seja dependente do seu estado. A resposta para uma mensagem específica varia de acordo com o estado do objeto.
© 2003 Jaelson Castro
Padrões de Projeto 83
Padrão Comportamental: State Forças:
O objeto tem comportamento complexo que deve ser dividido em elementos menos complexos. Uma ou mais operações têm comportamento que variam de acordo com o estado do objeto.
Tipicamente a operação teria muitas sentenças condicionais dependentes do estado.
Uma abordagem é ter operações públicas separadas para cada estado, mas objetos cliente precisam saber o estado do objeto para poderem chamar a operação adequada
© 2003 Jaelson Castro
Padrões de Projeto 84
Padrão Comportamental: State
Solução: Separar o estado dependente do comportamento do
objeto original e alocar este comportamento para um série de outros objetos, um para cada estado.
Estes objetos estado têm apenas responsabilidade para o comportamento daquele estado.
Contextoperation( )
State {abstract}operation( )
ConcreteStateA ConcreteStateB
Operation( ) Operation( )
© 2003 Jaelson Castro
Padrões de Projeto 85
Participantes do Padrão State
Contexto define a interface de interesse para clientesmantém uma instância de uma subclasse ConcreteStateque define o estado corrente
Estado define uma interface para encapsulamento do comportamento associado com um estado específico do Contexto
Subclasses ConcreteStatecada subclasse implementa um comportamento associado com um estado do Contexto
© 2003 Jaelson Castro
Padrões de Projeto 86
Padrão Comportamental: State Vantagens:
Comportamento do estado é localizado e o comportamento para diferentes estados é separado. Isto facilita qualquer modificação do comportamento do estado, em particular a adição de estados extra.
Transições de estado são explícitas. O objeto estado que está ativo, indica o estado atual do objeto Contexto.
© 2003 Jaelson Castro
Padrões de Projeto 87
Padrão Comportamental: State Desvantagens:
Objeto estado pode ser criado e removido quando o objeto Contexto muda o estado, introduzindo assim um overhead no processamento.
O uso do padrão estado introduz pelo menos uma mensagem extra, a mensagem da classe Contexto para classe Estado, adicionando assim mais overhead no processamento.
© 2003 Jaelson Castro
Padrões de Projeto 88
Padrão State : Um Sistema de Biblioteca
LoanStatus {abstract}CheckOut
Available OnLoan
CheckOut CheckOut
Copy
CheckOut
Available::CheckOut (book; user) //Check out book to a user
OnLoan::CheckOut (book; user)//Error: ‘Book already out’
•As subclasses concretas definem o método de acordo com o estado que elas representam
© 2003 Jaelson Castro
Padrões de Projeto 89
Padrão State : Agate
© 2003 Jaelson Castro
Padrões de Projeto 90
Padrão Chain of Responsability Intenção
Evita o acoplamento do remetente de uma solicitação ao seu receptor, ao dar a mais de um objeto a oportunidade de tratar uma solicitação. Encadeia os objetos receptores, passando a solicitação ao longo da cadeia até que um objeto a trate.
Motivação Help sensível ao contexto: O usuário pode obter
ajuda em qualquer parte da interface simplesmente pressionando o botão do mouse sobre ela. A ajuda depende da parte selecionada e do seu contexto.
© 2003 Jaelson Castro
Padrões de Projeto 91
Chain of Responsability Estrutura do Padrão
Handler
HandleRequest()
ConcreteHandler1HandleRequest()
ConcreteHandler2HandleRequest()
client sucessor
HelpHandler
PrintButtonPrintDialogue
© 2003 Jaelson Castro
Padrões de Projeto 92
Chain of Responsability Participantes
Handler Define uma interface para tratar solicitações. Implementa o elo ao sucessor.
ConcreteHandler Trata de solicitações pelas quais é responsável. Pode acessar o seu sucessor. Se o ConcreteHandler pode tratar a solicitação, ele o
faz; caso contrário, ele a repassa para o seu sucessor.
Client Inicia a solicitação para um objeto ConcreteHandler
da cadeia.
© 2003 Jaelson Castro
Padrões de Projeto 93
Chain of Responsability Aplicabilidade
Use o Padrão Chain of Responsability quando: Mais de um objeto pode tratar uma solicitação
e o objeto que a tratará não é conhecido a priori. O objeto que trata a solicitação deve ser escolhido automaticamente;
Você quer emitir uma solicitação para um dentre vários objetos, sem especificar explicitamente o receptor;
O conjunto de objetos que pode tratar uma solicitação deve ser especificado dinamicamente.
© 2003 Jaelson Castro
Padrões de Projeto 94
Chain of Responsability Colaborações
Quando um cliente emite uma solicitação, a mesma se propaga ao longo da cadeia até que um objeto ConcreteHandler assume a responsabilidade de tratá-la.
© 2003 Jaelson Castro
Padrões de Projeto 95
Chain of Responsability Conseqüências
Acoplamento reduzido entre cliente e receptor
Flexibilidade na atribuição de responsabilidades a objetos. A cadeia pode ser modificada em tempo de execução
A solicitação não é garantida de ser tratada
© 2003 Jaelson Castro
Padrões de Projeto 96
Padrão Iterator Intenção
Fornecer um meio de acessar, sequencialmente, os elementos de um objeto agregado sem expor a sua representação interna.
MotivaçãoList
Count()Append(Element)Remove(Element)...
ListIterator
First()Next()IsDone()CurrentItem()
list
© 2003 Jaelson Castro
Padrões de Projeto 97
Padrão Iterator Estrutura
AggregateCreateIterator()
Iterator
First()Next()IsDone()CurrentItem()
client
ConcreteAggregateCreateIterator()
Return new ConcreteIerator(this)
ConcreteIterator
© 2003 Jaelson Castro
Padrões de Projeto 98
Iterator Participantes
Iterator Define uma interface para acessar e percorrer
elementos. ConcreteIterator
Implementa a interface de Iterator. Mantém o controle da posição corrente no percurso do
agregado. Aggregate
Define uma interface para a criação de um objeto Iterator.
ConcreteAggregate Implementa a interface de criação do Iterator para
retornar uma instância do ConcreteIterator apropriado.
© 2003 Jaelson Castro
Padrões de Projeto 99
Padrão IteratorColaborações
Um ConcreteIterator mantém o controle do objeto corrente no agregado e pode computar o objeto sucessor no percurso.
© 2003 Jaelson Castro
Padrões de Projeto 100
Padrão IteratorAplicabilidade
Para acessar os conteúdos de um objeto agregado sem expor a sua representação interna;
Para fornecer uma interface uniforme que percorra diferentes estruturas agregadas (iteração polimórfica).
© 2003 Jaelson Castro
Padrões de Projeto 101
Padrão Observer Intenção
Definir uma dependência um-para-muitos entre objetos, de maneira que quando um objeto muda o seu estado todos os seus dependentes são notificados e atualizados automaticamente.
Motivação Separação das classes de apresentação das
classes de aplicação (ex: visualizadores para C e Java de árvores sintáticas)
© 2003 Jaelson Castro
Padrões de Projeto 102
Padrão ObserverEstrutura
ConcreteSubject
GetState()SetState()subjectState
Subject
Attach(Observer)Dettach(Observer)Notify()
return subjectState;
ObserverUpdate()
For all o in observers { o.Update}
ConcreteObserver
Update()observerState
observers
subject
observerState = subject.GetState;
© 2003 Jaelson Castro
Padrões de Projeto 103
Padrão ObserverParticipantes
Subject Conhece os seus observadores. Um número qualquer
de objetos Observer pode observar um subject. Fornece uma interface para acrescentar e remover
objetos observers. Observer
Define uma interface de atualização para objetos que devem ser notificados sobre mudanças em um Subject.
ConcreteSubject Armazena estados de interesse para objetos
ConcreteObserver. Envia uma notificação para os seus observadores
quando seu estado muda.
© 2003 Jaelson Castro
Padrões de Projeto 104
Padrão ObserverParticipantes
ConcreteObserver Mantém uma referência para um objeto
ConcreteSubject. Armazena estados que devem permanecer
consistentes com os do Subject. Implementa a interface de atualização de Observer,
para manter seu estado consistente com o do subject.
© 2003 Jaelson Castro
Padrões de Projeto 105
Padrão ObserverColaborações
O ConcreteSubject notifica seus observadores sempre que ocorrer uma mudança que pode tornar inconsistente o estado deles com o seu próprio.
Após ter sido informado de uma mudança no subject concreto, um objeto ConcreteObserver pode consultar o subject para obter informações. O ConcreteObserver usa esta informação para reconciliar o seu estado com aquele do subject.
© 2003 Jaelson Castro
Padrões de Projeto 106
Padrão Observer Aplicabilidade
Quando uma abstração tem dois aspectos, um dependente do outro. Encapsulando esses aspectos em objetos separados, permite-se variá-los e reutilizá-los independentemente.
Quando uma mudança em um objeto exige mudanças em outros, e você não sabe quantos objetos necessitam ser mudados.
© 2003 Jaelson Castro
Padrões de Projeto 107
Padrões GOF 23
Criação (5) Estrutura (7) Comportamento (11)
© 2003 Jaelson Castro
Padrões de Projeto 108
Padrões de Criação: Objeto
Único (Singleton) Garante que uma classe tenha apenas uma única
instância, e oferece um ponto global para acessá-la. Fábrica Abstrata (Abstract Factory)
Oferece uma interface para criar famílias de objetos relacionados sem especificar suas classes concretas.
Construtor (Builder) Separa a construção de um objeto complexo de sua
representação, então o mesmo processo de construção pode criar diferentes representações.
Protótipo (Prototype) Especifica os tipos de objetos para criar usando uma
instância prototípica, e cria novos objetos copiando deste protótipo.
© 2003 Jaelson Castro
Padrões de Projeto 109
Padrões de Criação: Classe Método Factory
Define uma interface para criação de um objeto, mas deixa a subclasse decidir que classe instancia.
Permite a classe retardar a instanciação da subclasse.
© 2003 Jaelson Castro
Padrões de Projeto 110
Padrões Estruturais: Objeto
Adaptador (Adapter) Converte a interface de uma classe em outra
interface que os clientes esperam. Ponte (Bridge)
Desacopla uma abstração da sua implementação, as duas podem variar independentemente (herança em tempo de execução)
Composto (Composite) Compõe objetos em três estruturas para
representar hierarquias parte-todo. Composto permite que clientes tratem tanto os objetos individuais quanto as composições de objetos uniformemente.
© 2003 Jaelson Castro
Padrões de Projeto 111
Padrões Estruturais: Objeto Decorador (Decorator)
Anexa responsabilidades adicionais para um objeto dinamicamente.
Fachada (Façade) Oferece uma interface unificada para um conjunto
de interfaces de um subsistema. Peso Mosca (Flyweight)
Usa compartilhamento para apoiar um grande número de objetos de fina granularidade eficientemente.
Proxy Oferece lugar de acesso para outro objeto controlar
o acesso.
© 2003 Jaelson Castro
Padrões de Projeto 112
Padrões Estruturais: Classe
Adaptador (Adapter) Converte a interface de uma classe
para outra interface que os clientes esperam.
Base de Template (Template Base) Usa classes base do template para
especificar associações.
© 2003 Jaelson Castro
Padrões de Projeto 113
Padrões Comportamentais: Objeto
Cadeia de Responsabilidade Evita o acoplamento do emissor de um
pedido ao seu receptor através da chance de mais de um objeto em mudar seu pedido
Observador (Observer) Quando um objeto muda de estado,
todos os seus dependentes são notificados e atualizados automaticamente.
© 2003 Jaelson Castro
Padrões de Projeto 114
Padrões Comportamentais: Objeto (cont.)
Iteração (Iterator) Oferece uma maneira para acessar os
elementos de um objeto agregado sequencialmente sem expor a sua representação.
Mediador (Mediator) Define um objeto que encapsula como
um conjunto de objetos que interagem entre si.
© 2003 Jaelson Castro
Padrões de Projeto 115
Padrões Comportamentais: Objeto (cont.) Comando
Encapsula a requisição como um objeto. “Memento”
Captura e externaliza um estado interno do objeto para que este estado possa ser recuperado depois.
Estado Permite que um objeto altere seu
comportamento quando seu estado interno muda.
© 2003 Jaelson Castro
Padrões de Projeto 116
Padrões Comportamentais: Objeto (cont.)
Estratégia Define uma família de algoritmos,
encapsula cada um, e torna-os inter-cambiáveis.
Visitante Representa uma operação a ser
realizada para os elementos da estrutura de um objeto.
© 2003 Jaelson Castro
Padrões de Projeto 117
Padrões Comportamentais: Classe
Interpretador Dada uma linguagem, define uma
representação para sua gramática com um interpretador que usa a representação para interpretar sentenças na linguagem.
Template de método Permite que subclasses redefinam
certos passos de um algoritmo sem alterar a estrutura do algoritmo.
© 2003 Jaelson Castro
Padrões de Projeto 118
Usando Padrões
Existe um padrão que trata um problema similar?
O contexto do padrão é consistente com o problema real?
As conseqüências do uso de padrão são aceitáveis?
© 2003 Jaelson Castro
Padrões de Projeto 119
Usando Padrões (cont.)
O padrão dispara uma solução alternativa que pode ser mais aceitável?
Existe uma solução mais simples? Existem algumas restrições de
conflito que sejam impostas pelo ambiente de software que está sendo usado?
© 2003 Jaelson Castro
Padrões de Projeto 120
Catálogo de Padrões
Padrões colecionados num catálogo precisam ser agrupados.
Projetistas descobrindo novos padrões precisam considerar onde o seu novo padrão se encaixa no catálogo.
Todos os usuários precisam ser atualizados no conteúdo do catálogo
© 2003 Jaelson Castro
Padrões de Projeto 121
Armazenando e Procurando Padrões Manutenção da documentação de
padrões Procura de facilidades disponíveis Agrupamento de padrões Publicação de padrões disponíveis Uso de fontes, tipos, ênfase, etc.
© 2003 Jaelson Castro
Padrões de Projeto 122
Benefícios do Uso de Padrões
Eles oferecem um mecanismo para reusar soluções genéricas.
Eles oferecem um vocabulário para discutir o domínio do problema no mais alto nível de abstração, tornando mais fácil considerar aspectos micro arquiteturais.
© 2003 Jaelson Castro
Padrões de Projeto 123
Perigos do Uso de Padrões Algumas pessoas acreditam que o uso de
padrões possa limitar a criatividade. O uso de padrões de uma maneira
descontrolada pode originar projetos carregados.
Desenvolvedores: Precisam de tempo para entender os catálogos
de padrões relevantes Precisam de fácil acesso para catálogos
relevantes Precisam ser treinados no uso de padrões
© 2003 Jaelson Castro
Padrões de Projeto 124
Leituras Adicionais
Gamma E, Helm R, Johnson R and Vlissides J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley 1994.