©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/65 Padrões de Projeto.

CIn-UFPECIn-UFPE 11/65/65©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio

Padrões de ProjetoPadrões de Projeto


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


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


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.


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


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


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


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.


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


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


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


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


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


Alguns ExemplosAlguns Exemplos

Padrão Composite (estrutural) Padrão Singleton (criacional) Padrão State (comportamental)


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.



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



Solução : Combinar hierarquias de herança e agregação.



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.


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..*


Outro Exemplo do Padrão Composite: Outro Exemplo do Padrão Composite: Campanhas de MidiaCampanhas de Midia


Padrão Composite:Padrão Composite:Exemplo de UsoExemplo de Uso

Diretórios e arquivos em um sistema de arquivos


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.



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).



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.



Singletonstatic uniqueInstancesingletonData

getInstance()getSingletonData() singletonOperation()

return uniqueInstance



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.


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


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.


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.



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



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.



Contextoperation( )

State {abstract}operation( )

ConcreteStateA ConcreteStateB

operation( ) operation( )


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



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.



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.


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


Padrão Padrão StateState: : Exemplo de CampanhasExemplo de Campanhas


Padrões de Projeto para Padrões de Projeto para Arquitetura em CamadasArquitetura em Camadas


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.


Padrão Façade: Padrão Façade: Estrutura e ParticipantesEstrutura e Participantes

Façadesubsystem classes

Client


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.


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.


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.


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.



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.



BusinessCollectionspecificSystemService()

<<Interface>> IBusinessDatainsert()remove()update()search()

Façade

PersistentDataCollection

insert()remove()update()search()

BusinessBasic

<<Interface>> IPersistenceMechanismbeginTransaction()connect()commit()

PersistenceMechanismbeginTransaction()connect()commit()

1..*

0..*


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

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














©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/65 Padrões de Projeto.

Documents

Transcript of ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/65 Padrões de Projeto.