Upload
mario-aires-macedo
View
213
Download
0
Embed Size (px)
Citation preview
CIn-UFPECIn-UFPE 11/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrões de ProjetoPadrões de Projeto
CIn-UFPECIn-UFPE 22/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
ObjetivosObjetivos
Explicar: O que é um padrão de projeto Alguns padrões que já foram 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 de projeto
CIn-UFPECIn-UFPE 33/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
MotivaçãoMotivação
Projetar software OO reusável e de boa qualidade é 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 Uso sistemático de:
nomes, explicações, e avaliações
Durante a última década, uma “comunidade de padrões” foi desenvolvida
CIn-UFPECIn-UFPE 44/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Algumas definiçõesAlgumas definições
“Cada padrão descreve um problema que ocorre freqüentemente em seu ambiente, e então descreve o núcleo de uma solução para o problema, de maneira que você possa usar esta solução um milhão de vezes, sem fazê-la do mesmo jeito duas vezes.” Christopher Alexander (Arquiteto e Urbanista), 1977
“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
“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.
CIn-UFPECIn-UFPE 55/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Características dos Padrões de Projeto Características dos Padrões de Projeto de Softwarede Software
Algo comprovado que captura e comunica os conhecimentos das melhores práticas
Descoberto, não inventado Soluções Sucintas e de Fácil Aplicação
Capturam, de forma sucinta e facilmente aplicável, soluções de projeto de programas de computador que foram desenvolvidas e evoluíram com o passar do tempo
Soluções Exaustivamente Refinadas Resultados de um longo processo de projeto, re-projeto, teste e
reflexão sobre o que torna um sistema mais flexível, reusável, modular e compreensível
Soluções Compartilhadas Construídas em grupo Através do uso de um vocabulário comum
CIn-UFPECIn-UFPE 66/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Outros Tipos de PadrõesOutros Tipos de Padrões
Padrões de Análise: Descrevem 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: Descrevem a estrutura e o relacionamento dos
componentes de um sistema de software Padrões de Processo
CIn-UFPECIn-UFPE 88/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Princípios Presentes nos PadrõesPrincí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 interface e implementação Único ponto de referência Dividir para conquistar
CIn-UFPECIn-UFPE 1010/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Elementos para Documentação de um Elementos para Documentação de um Padrão de ProjetoPadrão de Projeto
Nome: Resume em uma ou duas palavras: o problema, as soluções e conseqüências do uso do padrão. Deve ser facilmente lembrado, reflete o conteúdo do padrão.Problema: Descreve quando aplicar o padrão. Explica o problema e seu contexto. Sintomas e condições.Solução: Elementos que constituem o design, seus relacionamentos, responsabilidades e colaboradores.Conseqüências: Resultados e compromissos decorrentes da aplicação do padrão.
Impactos sobre a flexibilidade, extensibilidade, portabilidade ou desempenho do sistema.
CIn-UFPECIn-UFPE 1111/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Outros Elementos para Documentação Outros Elementos para Documentação
Um exemplo de uso A razão que justifica a solução escolhida Padrões relacionados Uso conhecido do padrão Lista de outros nomes para o padrão Amostra de código em uma linguagem de
programação
CIn-UFPECIn-UFPE 1212/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Tipos de Padrões de ProjetoTipos de 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: Estruturais (7) Criacionais (5) Comportamentais (11)
divididos em 2 escopos: Classe Objeto
CIn-UFPECIn-UFPE 1313/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
EscopoEscopo
Classe Relacionamentos entre classes e suas subclasses Não é preciso executar nenhum código para determinar o
uso dos padrões Estáticos: fixos em tempo de compilação
Objeto Confia em ponteiros de objetos Dinâmicos: relacionamentos entre objetos podem ser
alterados em tempo de execução
CIn-UFPECIn-UFPE 1414/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Detalhamento dos Tipos de PadrõesDetalhamento dos Tipos de Padrões
Estruturais Tratam de compor classes e objetos para formar estruturas
grandes e complexas Associados à maneira como classes e objetos são
organizados estruturalmente Oferecem formas efetivas para usar conceitos OO como
herança, agregação e composição Focam na abstração da estrutura
CIn-UFPECIn-UFPE 1515/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Detalhamento dos Tipos de PadrõesDetalhamento dos Tipos de Padrões
Criacionais Associados ao processo de criação de objetos Tornam um sistema independente de como seus objetos
são criados, compostos e representados Comportamentais
Tratam de algoritmos e como atribuir responsabilidades entre objetos
Associados à maneira que objetos e classes distribuem suas responsabilidades para realizar uma tarefa
Focam na abstração do comportamento
CIn-UFPECIn-UFPE 1616/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Alguns ExemplosAlguns Exemplos
Padrão Composite (estrutural) Padrão Singleton (criacional) Padrão State (comportamental)
CIn-UFPECIn-UFPE 1717/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão Estrutural: CompositePadrão Estrutural: Composite
Nome: Composite Problema:
Se existe um requisito para representar hierarquias todo-parte, então ambos objetos (todo e parte) oferecem a mesma interface para objetos cliente.
Contexto: Numa aplicação tanto o objeto que contém quanto o que é
componente devem oferecer o mesmo comportamento. Objetos cliente devem ser capazes de tratar objetos compostos
ou componentes do mesmo jeito.
CIn-UFPECIn-UFPE 1818/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão Estrutural: CompositePadrão Estrutural: Composite
Forças: O requisito que os objetos, tanto composto como
componente, ofereçam a mesma interface, sugere que eles pertençam à 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 de uma estrutura de agregação
CIn-UFPECIn-UFPE 1919/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão Estrutural: CompositePadrão Estrutural: Composite
Solução : Combinar hierarquias de herança e agregação.
CIn-UFPECIn-UFPE 2020/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão Estrutural: CompositePadrão Estrutural: Composite
Solução: Ambas subclasses, Leaf e Composite, têm uma operação
redefinida usando 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.
CIn-UFPECIn-UFPE 2121/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Exemplo do Padrão Composite: Graphical Exemplo do Padrão Composite: Graphical drawing packagedrawing package
Graphic
drawgetChildremoveGraphicaddGraphic
CompositeGraphic
drawgetChildremoveGraphicaddGraphic
Line
draw
Rectangle
draw
Circle
draw
Client
0..*
CIn-UFPECIn-UFPE 2222/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Outro Exemplo do Padrão Composite: Outro Exemplo do Padrão Composite: Campanhas de MidiaCampanhas de Midia
CIn-UFPECIn-UFPE 2323/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão Composite:Padrão Composite:Exemplo de UsoExemplo de Uso
Diretórios e arquivos em um sistema de arquivos
CIn-UFPECIn-UFPE 2424/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão de Criação: SingletonPadrão de Criação: Singleton
Nome: Singleton 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.
CIn-UFPECIn-UFPE 2525/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão de Criação: SingletonPadrão de Criação: Singleton
Forças: Uma abordagem para tornar um objeto acessível
globalmente é colocá-lo como uma variável global. Outra abordagem é não criar uma instância de objeto em
nenhum lugar, mas usar operações e atributos de classe (chamados ‘static’ em C++ e Java).
CIn-UFPECIn-UFPE 2626/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão de Criação: SingletonPadrão de Criação: Singleton
Solução: Criar uma classe com uma operação 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 a getInstance() nenhuma instância
adicional é criada, mas a identidade do objeto existente é retornada.
CIn-UFPECIn-UFPE 2727/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão de Criação: SingletonPadrão de Criação: Singleton
Singletonstatic uniqueInstancesingletonData
getInstance()getSingletonData() singletonOperation()
return uniqueInstance
CIn-UFPECIn-UFPE 2828/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão de Criação: SingletonPadrão de Criação: Singleton
Vantagens: Oferece acesso controlado à única instância do objeto, pois
a classe Singleton encapsula a instância. 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.
CIn-UFPECIn-UFPE 2929/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão Singleton: Um Exemplo de UsoPadrão Singleton: Um Exemplo de Uso
O sistema de gerenciamento de campanhas de uma empresa precisa guardar informações a respeito da empresa.
Estas informações só devem ser guardadas em um único lugar dentro da aplicação, mas serão usadas por diferentes objetos.
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
CIn-UFPECIn-UFPE 3030/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão Singleton: ExemploPadrão Singleton: Exemplo
CIn-UFPECIn-UFPE 3131/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão Singleton: ExemploPadrão Singleton: Exemplo
Mas a companhia opera como uma empresa separada em cada país diferentes detalhes registrados da empresa para cada país
A classe Company só é instanciada uma vez. Ela é acessível globalmente.
Diferentes subclasses de Company são instanciadas quando necessário, dependendo das circunstâncias em tempo de execução.
CIn-UFPECIn-UFPE 3232/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão Singleton: ExemploPadrão Singleton: Exemplo
CIn-UFPECIn-UFPE 3333/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão Comportamental: StatePadrã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.
CIn-UFPECIn-UFPE 3434/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão Comportamental: StatePadrã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 diferentes para cada estado, mas objetos cliente precisariam saber o estado do objeto para poderem chamar a operação adequada
CIn-UFPECIn-UFPE 3535/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão Comportamental: StatePadrã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 relacionadas ao comportamento do respectivo estado.
CIn-UFPECIn-UFPE 3636/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão Comportamental: StatePadrão Comportamental: State
Contextoperation( )
State {abstract}operation( )
ConcreteStateA ConcreteStateB
operation( ) operation( )
CIn-UFPECIn-UFPE 3737/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Participantes do Padrão StateParticipantes do Padrão State
Context define a interface de interesse para clientes.Mantém uma instância de uma subclasse
ConcreteStateque define o estado corrente
State 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
CIn-UFPECIn-UFPE 3838/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão Comportamental: StatePadrão Comportamental: State
Vantagens: O comportamento do estado é localizado e o
comportamento para diferentes sub-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.
CIn-UFPECIn-UFPE 3939/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão Comportamental: StatePadrão Comportamental: State
Desvantagens: O objeto Estado pode ser criado ou removido quando o
objeto Context muda o estado, introduzindo assim um overhead no processamento.
O uso do padrão State introduz pelo menos uma mensagem extra, a mensagem da classe Context para classe State, adicionando assim mais overhead no processamento.
CIn-UFPECIn-UFPE 4040/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão State: Um Sistema de BibliotecaPadrão State: Um Sistema de Biblioteca
LoanStatus {abstract}CheckOut
Available OnLoanCheckOut CheckOut
CopyCheckOut
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
CIn-UFPECIn-UFPE 4141/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão Padrão StateState: : Exemplo de CampanhasExemplo de Campanhas
CIn-UFPECIn-UFPE 5656/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrões de Projeto para Padrões de Projeto para Arquitetura em CamadasArquitetura em Camadas
CIn-UFPECIn-UFPE 5757/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão FaçadePadrão Façade
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.
CIn-UFPECIn-UFPE 5858/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão Façade: Padrão Façade: Estrutura e ParticipantesEstrutura e Participantes
Façadesubsystem classes
Client
CIn-UFPECIn-UFPE 5959/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão Façade: Padrão Façade: AplicabilidadeAplicabilidade
Use o Padrão Façade quando: Você quer prover uma interface simplificada para um
subsistema complexo. Um Façade pode prover uma visão simples do subsistema, suficiente para a maioria dos clientes
Existem muitas dependências entre clientes e classes da implementação. O Façade reduz esta dependência e promove independência e portabilidade
Você quer criar sistemas em camadas. Um Façade provê o ponto de entrada para cada camada (nível) do subsistema.
CIn-UFPECIn-UFPE 6060/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão Façade: Padrão Façade: ConseqüênciasConseqüências
Promove acoplamento fraco entre o subsistema e seus clientes
No entanto, não evita que aplicações possam acessar diretamente as subclasses do sistema, se assim o desejarem.
CIn-UFPECIn-UFPE 6161/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão Padrão Persistent Data Collections (PDC)Persistent Data Collections (PDC)
Nome: PDC Problema: Como melhorar os níveis de manutenção
e reuso quando usando mecanismos de persistência em aplicações orientadas a objeto?
Contexto: Durante o desenvolvimento de aplicações orientadas a objeto que utilizam mecanismos de persistência, através de APIs (Application Programming Interfaces) específicas, é possível que o código gerado misture a lógica da aplicação com os mecanismos de persistência, dificultando assim a manutenção e o reuso.
CIn-UFPECIn-UFPE 6262/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão PDCPadrão PDC
Forças: Desenvolvedores devem poder endereçar os aspectos de
negócio de uma organização independente das operações de persistência.
O mecanismos de persistência podem mudar durante o período de vida da aplicação.
Classes de negócio podem ser usadas por outras aplicações.
O mecanismo de persistência deve lidar de forma eficiente com a habilitação de conexões com o banco de dados e com o gerenciamento de transações.
A performance do sistema não deve ser afetada.
CIn-UFPECIn-UFPE 6363/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão PDCPadrão PDC
Solução: Separar as classes de análise em duas categorias:
Classes descrevendo os objetos de negócio. Classes para a manipulação e armazenamento de dados, com
código específico para o tratamento de persistência.
CIn-UFPECIn-UFPE 6464/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Padrão PDCPadrão PDC
BusinessCollectionspecificSystemService()
<<Interface>> IBusinessDatainsert()remove()update()search()
Façade
PersistentDataCollection
insert()remove()update()search()
BusinessBasic
<<Interface>> IPersistenceMechanismbeginTransaction()connect()commit()
PersistenceMechanismbeginTransaction()connect()commit()
1..*
0..*
CIn-UFPECIn-UFPE 6565/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio
Leituras AdicionaisLeituras Adicionais
Gamma E, Helm R, Johnson R and Vlissides J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley 1994.
http://gee.cs.oswego.edu/dl/cpj/ifc.html http://st-www.cs.uiuc.edu/cgi-bin/wikic/wikic?
JavaAWT http://mordor.cs.hut.fi/tik-76.278/group6/awtpat.html http://jurema.cin.ufpe.br:8080/twiki/pub/Main/
GenteAreaPublications/PersistentDataCollectionsPLOP2001.pdf