© 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



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



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.



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.



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)



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.



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



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



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.



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)



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



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



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.



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



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



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)



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.



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.



Padrão criação Abstraem o processo de criação de

instâncias (objetos), oferecendo flexibilidade no que é criado, por quem, como e quando.



Alguns Exemplos Padrão criação

Singleton Abstractfactory Builder FactoryMethod Prototype



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.



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



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.



Padrão de Criação: Singleton Estrutura:

Singleton

static uniqueInstancesingletonData

getInstance()singletonOperation()getSingletonData()

return unique instance



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.



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.



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



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



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.



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



AbstractFactory Estrutura do Padrão

AbstractFactory

createProductA()createProductB()

ConcreteFactory1createProductA()createProductB()

ConcreteFactory2createProductA()createProductB()

abstractProductA

abstractProductB

client

productA2

productB2

productA1

productB1MotifWidgetFactory

Widget Factory

PMWidgetFactory

Window

ScrollBar



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



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



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)



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



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



Padrão BuilderEstrutura e Participantes

Director

construct()

builder

for all objects in structure { builder.buildPart();}

AbstractBuilder

buildPart()

Product1

ConcreteBuilder2

buildPart()getResult()

Product2

ConcreteBuilde3r


Product3

builders

ConcreteBuilder1


TextConverter

ASCIIConverter

TeXConverter

WordConverter

ASCIIText TeXText WordText

RTFReader



Padrão BuilderColaborações

aBuilder = new ConcreteBuilder()

aClient aBuilderaDirector

aDirector = new Director(aBuilder)

aDirector.construct()

aBuilder.buildPartA()

aBuilder.buildPartB()

aBuilder.buildPartC()

aBuilder.getResult()



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



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



Padrão FactoryMethodEstrutura e Participantes

...Product p = factoryMethod();...

Creator

factoryMethod()Product

ConcreteCreator

factoryMethod()

ConcreteProduct

operation()

return new ConcreteProduct();

Document

MyDocument

Application

MyApplication



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



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



Padrão PrototypeParticipantes e Colaboradores

...p = prototype.clone();...

Cliente Prototype

clone()operation()

ConcretePrototype1

clone()

ConcretePrototype2

clone()

prototypeFerramentaGráfica Gráfico

Pauta Breve



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



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



Padrão Estrutural

Tratam de compor classes e objetos para formar estruturas grandes e complexas



Padrão Estrutural:Exemplo

Composite Adapter Bridge Decorator Facade Flyweight Proxy



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)



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



Padrão Estrutural: Composite

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



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.



Padrão Composite : Graphical drawing package

Graphic

drawgetChildremoveGraphicaddGraphic

CompositeGraphic

drawgetChildremoveGraphicaddGraphic

Line

draw

Rectangle

draw

Circle

draw

Client0..*



Padrão Composite : Agate



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



specificRequest()

Client Target

request()

Adapter

request()

Adaptee

specificRequest()

Padrão (Class)AdapterEstrutura e Participantes

Usando Herança Múltipla



adaptee.specificRequest();

Client Target

request()

Adapter

request()

Adaptee

specificRequest()

Padrão (Object)AdapterEstrutura e Participantes

Usando Composição

adaptee

DrawingEditor

Shape

TextShape

TextView



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.



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.



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



Padrão BridgeEstrutura e Colaboradores

Implementor

operationImp()

ConcreteImplementorA

operationImp()

ConcreteImplementorB

operationImp()

Abstraction

operation()

imp

imp.operationImpl();

RefinedAbstraction

Client

WindowWindowImp

IconWindowXWindowImp PMWindowImp



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



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



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.



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



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



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.



Padrão FacadeEstrutura e Participantes

Facadesubsystem classes

Client Compilador

Parser

Scanner

Token



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.



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.



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.



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


Flyweight


intrinsincState allState

Glyph

Character Row, Collumn



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.



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



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.



Padrão Proxy Estrutura e Colaboradores

RealSubject

request()...

Client

Proxy

request()...

Subject

request()

realSubject.request();

Graphic

ImageImageProxy



Padrão Proxy Conseqüências

Acrescenta um nível de indireção adicional



Padrão Comportamental

Preocupam-se com algoritmos e a atribuição de responsabilidades entre objetos. Descrevem padrões de comunicação entre os objetos.



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



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.



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



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



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



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.



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.



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



Padrão State : Agate



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.



Chain of Responsability Estrutura do Padrão

Handler

HandleRequest()

ConcreteHandler1HandleRequest()

ConcreteHandler2HandleRequest()

client sucessor

HelpHandler

PrintButtonPrintDialogue



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.



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.



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.



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



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



Padrão Iterator Estrutura

AggregateCreateIterator()

Iterator

First()Next()IsDone()CurrentItem()

client

ConcreteAggregateCreateIterator()

Return new ConcreteIerator(this)

ConcreteIterator



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.



Padrão IteratorColaborações

Um ConcreteIterator mantém o controle do objeto corrente no agregado e pode computar o objeto sucessor no percurso.



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



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)



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;



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.



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.



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.



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.



Padrões GOF 23

Criação (5) Estrutura (7) Comportamento (11)



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.



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.



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.



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.



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.



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.



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.



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.



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.



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.



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?



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?



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



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.



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.



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



Leituras Adicionais

Gamma E, Helm R, Johnson R and Vlissides J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley 1994.

© 2001 jaelson castropadrões de projeto 1 padrões de projeto

Documents