Programao Orientada a Objetos Padres de Projeto (design patterns)

Fernando Vanini IC - UNICAMP

Padres de Projeto (design patterns)

Apresentao do conceito de design pattern Classificao dos design patterns Catlogo Uso dos design patterns

Design Patterns
medida que se acumula experincia em projetos usando objetos, observa-se que determinadas situaes de colaborao entre objetos se repetem, independentemente da tecnologia ou linguagem de programao utilizada. Alguns autores (Gamma et. al.) catalogaram um conjunto de solues de projeto (em ingles design patterns) que consideraram representativas e desde ento, essas solues tem sido uma referncia importante para empresas e programadores em geral.

Um exemplo
Uma aplicao com interface grfica precisa ser implementada de forma portvel para diversas plataformas grficas, como por exemplo Motif e Gnome. O padro Abstract Factory aplicvel a esse tipo de situao

Um exemplo Abstract Factory

Abstract Factory
No padro Abstract Factory, ou Fbrica Abstrata, a aplicao cliente interage com uma 'fbrica genrica de objetos os objetos sero gerados efetivamente pela fbrica concreta que estiver sendo utilizada no momento a aplicao cliente no precisa ser configurada para interagir com cada uma das fbricas concretas novas fbricas concretas podem ser agregadas, alteradas ou retiradas do sistema sem necessidade de alteraes na aplicao cliente

Abstract Factory

Design Patterns: reuso da soluo

Ao se comparar o exemplo com a descrio genrica apresentada, nota-se que a cada nova situao, um novo cdigo dever ser escrito, apesar da estrutura ser basicamente a mesma. A principal idia por trs dos design patterns o reuso da soluo e no necessariamente o reuso do cdigo, como acontece no caso de bibliotecas.
8

Design Patterns: a origem

A idia de padres de projeto como forma de reusar solues recorrentes surgiu de um abordagem semelhante na rea de arquitetura (Cristopher Alexander). Um dos primeiros padres identificados na rea de software foi o modelo MVC (model, view, controller), que foi usado no projeto da interface de usurio da linguagem Smalltalk (Xerox).

O modelo MVC
No modelo MVC de arquitetura, o software organizado em trs camadas:
model responsvel pelo armazenamento e manuteno dos dados utilizados pela aplicao. view a camada responsvel pela interface com o usurio controller a camada responsvel pelo tratamento de eventos e implementao das regras de negcio (que normalmente implicam em mudanas nos dados atravs dos servios de model)

10

O modelo MVC

11

MVC motivao inicial

12

MVC numa aplicao web

13

MVC numa aplicao web

14

MVC - conseqncias
Vantagens
O mesmo modelo pode ser usado com diferentes vises (ou aplicaes diferentes). Novos tipos de clientes podem ser agregados aplicao, sem nenhum impacto para o modelo. Clareza e modularidade de projeto.

Desvantagens
Complexidade adicional, s justificvel em aplicaes de mdio e grande porte.

15

Design Patterns: classificao

para facilitar o estudo e uso dos design patterns, os autores os classificaram segundo dois critrios: finalidade e escopo A finalidade diz respeito ao que a soluo faz ou se prope a fazer. O escopo de um padro especifica se o padro se aplica primariamente a classes ou a objetos.

16

Design Patterns: finalidade

De acordo com a sua finalidade, os padres so classificados em
Padres de Criao(creational) - se preocupam com o processo de criao de objetos. Estruturais (structural) - lidam com a composio de classes ou de objetos. Comportamentais (behavioral) - tratam da forma pela qual classes ou objetos interagem e distribuem responsabilidades
17

Design Patterns: escopo

De acordo com a seu escopo, os padres so classificados em
padres para classes (class patterns): lidam com os relacionamentos entre classes e suas subclasses, estabelecidos atravs de herana, sendo portanto estticos (fixados em tempo de compilao). padres para objetos (object patterns) tratam de relacionamentos entre objetos que podem se alterar em tempo de execuo, portanto dinmicos. No catlogo oficial alguns padres so apresentados em duas verses, uma aplicvel a classes e outra aplicvel a objetos.
18

O Catlogo
O catlogo dos design patterns apresentado no seguinte formato:
nome e classificao do padro Inteno e objetivo Tambm conhecido como Motivao Aplicabilidade Estrutura Participantes Colaboraes Conseqncias Implementao Exemplos de Cdigo Usos conhecidos Padres Relacionados

19

Padres de Criao
Abstraem o processo de instanciao dos objetos, contribuindo para tornar o sistema independente de como seus objetos so criados, compostos e representados. Um padro de criao de classe usa herana para variar a classe sendo instanciada. Um padro de criao de objeto delega a instanciao a outro objeto.
20

Abstract Factory
Inteno: fornecer uma interface para a criao de famlias de objetos relacionados ou dependentes sem especificar suas classes completas Motivao: em muitas situaes uma aplicao cliente precisa criar determinados objetos cuja construo efetiva s definida em tempo de execuo. A aplicao cliente no deve se preocupar com a criao dos objetos.
21

Abstract Factory
Aplicabilidade: aplicvel a situaes nas quais
o sistema deve ser independente de como seus produtos so criados, compostos ou representados o sistema deve ser configurado como um produto de uma famlia de mltiplos produtos a famlia de objetos-produto projetada para ser usada em conjunto deseja-se revelar apenas a interface da biblioteca de classes-produto e no a sua implementao
22

Abstract Factory - estrutura

23

Abstract Factory
Colaboraes

Em tempo de execuo, normalmente criada uma nica instncia da classe ConcreteFactory. Ela ser a responsvel pela criao dos produtos concretos. AbstractFactory delega a criao dos objetos-produto para suas subclasses concretas (ConcreteFactory).
Conseqncias

Isola as classes concretas Facilita a troca de famlias de produtos difcil suportar novos tipos de produtos
Padres Correlatos

FactoryMethod, Prototype
24

Builder
Inteno: Separar a construo de um objeto complexo de
sua representao de modo que o mesmo processo de construo possa criar diferentes representaes.

Motivao: Um exemplo pode ser um leitor de documento

RTF capaz de converter o texto lido para vrios formatos diferentes, ficando aberto o nmero de converses possveis. Deve ser portanto fcil acrescentar uma nova converso sem modificar o leitor.
25

Builder
Aplicabilidade: aplicvel a situaes onde
O algoritmo para a criao de um objeto complexo deve ser independente das partes que compem o objeto e de como elas devem ser montadas. O processo de construo deve permitir diferentes representaes para o objeto que construdo.

26

Builder - Estrutura

27

Builder Um exemplo

28

Builder
Colaboraes
O cliente cria o objeto Director e o configura com o Builder desejado. O cliente notifica o Builder sempre que uma parte do produto deve ser construda Builder trata solicitaes e acrescenta partes ao produto O Cliente recupera o produto do construtor

29

Builder
Conseqncias
Permite variar a representao interna de um produto Isola o cdigo para a construo e representao Oferece um controle mais fino sobre o processo de construo

Padres Correlatos
Abstract Factory Composite
30

Factory Method
Inteno: Definir uma interface para a criao de um objeto, deixando as subclasses decidirem que classe instanciar. O FactoryMethod delega a instanciao para as subclasses. Motivao: Em muitas situaes, uma aplicao necessita criar objetos cujas classes fazem parte de uma hierarquia de classes, mas no necessita ou no tem como definir qual a subclasse a ser instanciada. O FactoryMethod usado nesses casos e decide com base do contexto, qual das subclasses ativar. Um exemplo simples: leitura de objetos serializados num arquivo.

31

Factory Method
Aplicabilidade: em casos tais que
O cliente no consegue antecipar a classe de objetos que deve criar. Uma classe quer que suas subclasses especifiquem os objetos que criam

Colaboraes
Creator depende das suas subclasses para definir o mtodo de construo necessrio retornar a instncia do produto concreto apropriado.

Conseqncias
Fornece ganchos para as subclasses. Conecta hierarquias de classe paralelas.

Padres Correlatos
Abstract Factory, Template Method

32

Factory Method - Estrutura

33

Factory Method Um exemplo

34

Factory Method
Colaboraes
Creator depende das suas subclasses para definir o FactoryMethod apropriado.

Conseqncias
Fornece ganchos para a subclasses Conecta hierarquia de classes paralelas

Padres Correlatos
Abstract Factory Composite TemplateMethod
35

Prototype
Inteno
Especificar os tipos de objetos a serem criados usando uma instncia prottipo e criar novos objetos copiando o prottipo.

Motivao
Uma ferramenta CAD em geral uma paleta de ferramentas e entre elas aquelas necessrias insero de figuras no projeto sendo editado. As figuras em geral so complexas e a sua replicao no projeto exige uma seqncia de operaes que particular de cada figura. Ao invs de se ter mtodos de construo especfico para cada figura, tem-se prottipos das figuras possveis, cada um oferecendo um mtodo clone() para a sua replicao.

36

Prototype
Aplicabilidade
Quando as classes a instanciar so especificads em tempo de execuo ou Deseja-se evitar uma hierarquia de classes de fbricas paralelas hierarquia principal ou As instncias de classe podem ter uma entre poucas combinaes diferentes de estados.

37

Prototype - Estrutura

38

Prototype
Colaboraes
Um cliente solicita um prottipo e este clona a si prprio. Este ser o responsvel pela criao dos produtos concretos.

Conseqncias
Permite acrescentar e remover produtos em tempo de execuo Especifica novos objetos pela variao de valores ou pela variao de estrutura Reduz o nmero de subclasses Configura dinamicamente as classes ou objetos da aplicao Cada subclasse deve implementar a operao clone(), o que pode ser difcil em alguns casos

Padres Correlatos
Abstract Factory, Composite

39

Singleton
Inteno
Garantir que uma classe tenha somente uma instncia e fornecer um ponto global de acesso mesma

Motivao
Em muitas situaes necessrio garantir que algumas classes tenham uma e somente uma instncia. Exemplo: o gerenciador de arquivos num sistema deve ser nico.

Aplicabilidade
Quando deva existir apenas uma instncia de uma classe e essa instncia deve dar acesso aos clientes atravs de um ponto bem conhecido.
40

Singleton - Estrutura

41

Singleton
Colaboraes
Os clientes acessam uma nica instncia do Singleton pela operao Instance() Acesso controlado instncia nica. Espao de nomes reduzido Permite o refinamento de operaes e da representao Permite um nmero varivel de instncias (!) Mais flexvel que operaes de classe (mtodos estticos no so polimrficos; no permitiriam nmero varivel de instncias).

Conseqncias

Padres Correlatos

AbstractFactory, Prototype, Builder

42

Padres Estruturais
Preocupam-se com a forma como classes e objetos so compostos para formar estruturas mariores. Utilizam herana pra compor interfaces ou implementaes. Descrevem formas de compor objetos para obter novas funcionalidades. Possibilidade de mudar a composio em tempo de execuo, o que impossvel com uma hierarquia de classes.
43

Adapter
Inteno
converter a interface de uma classe na interface esperada pelos clientes. O Adapter permite que classes com interfaces incompatveis trabalhem em conjunto.

Motivao
Em algumas situaes, a interface oferecida por um toolkit, projetada para ser reutilizada no pode ser usada numa aplicao porque sua interface no corresponde interface especfica.

Aplicabilidade
situaes nas quais as classes que devem interagir no tm interfaces compatveis adaptador de objetos aplicvel nos casos em que no possvel adaptar as classes existentes atravs de subclasses.

44

Adapter Estrutura (1)

45

Adapter Estrutura (2)

46

Adapter
Colaboraes
Os clientes chamam operaes de uma instncia de Adapter e este por sua vez chama as operaes de Adaptee que executam a solicitao. um adaptador de classe nao funciona se quisermos adaptar uma dada classe e todas as suas subclasses. possvel substituir algum comportamento do Adaptee, uma vez que Adapter uma subclasse de Adaptee. introduz somente um objeto intermedirio, no sendo necessrio endereamento indireto adicional at se chegar ao Adaptee.

Conseqncias (adaptador de classe)

47

Adapter
Conseqncias (adaptador de objetos)
permite a um nico Adapter trabalhar com muitos Ataptees. difcil redefinir o comportamento de um Adaptee. Para isso necessrio a criao de subclasses.

Pontos a considerar
o 'grau de adaptao' varia muito de uma situao para outra. adaptadores plugveis. adaptadores nos dois sentidos para fornecer transparncia

Padres Correlatos
Bridge, Decorator, Proxy
48

Bridge
Inteno
Desacoplar uma abstrao de sua implementao, de modo que as duas possam variar independentemente.

Motivao
Em alguns casos, uma abstrao pode ter mais de uma implementao possvel e herana no suficientemente flexvel porque liga de forma permanente a abstrao da implementao.
49

Bridge
Aplicabilidade
deseja-se evitar o vnculo permanente da abstrao e sua implementao. Isso pode ser necessrio, por exemplo, quando a implementao deve ser definida ou alterada em tempo de execuo. tanto as abstraes como suas implementaes devem ser extensveis por meio de subclasses. Atravs do padro Bridge possvel combinar as diferentes abstraes e implementaes e extende-las independentemente. deseja-se ocultar completamente a implementao dos clientes. necessrio compartilhar uma implementao entre mltiplos objetos.

50

Bridge - Estrutura

51

Bridge
Colaboraes
Abstraction repassa as solicitaes dos clientes para o seu objeto Implementor

Conseqncias
Desacopla a interface da implementao possvel estender as hierarquias de Abstraction e Implementor de forma independente capaz de ocultar detalhes de implementao dos clientes

Padres Correlatos
AbstractFactory, Adapter
52

Composite
Inteno
Compor objetos em estruturas que permitam aos clientes tratarem de maneira uniforme objetos individuais e composio de objetos.

Motivao
algumas aplicaes exigem que o mesmo tratamento seja dado tanto a objetos simples como estruturas formadas por vrios objetos. O padro Composite descreve como usar a composio de forma que os clientes no precisem distinguir objetos simples de estruturas complexas.

Aplicabilidade
representao de hierarquias todo-parte de objetos. clientes devem ser capazes de ignorar a diferena entre composies de objetos e objetos individuais.

53

Composite - Estrutura

54

Composite - Exemplo

55

Composite
Colaboraes
Os clientes usam a interface da classe Component para interagir com os objetos na estrutura composta. Se o receptor pertence classe Leaf ento a solicitao tratada diretamente. Se o receptor um Composite, ento ele normalmente repassa as solicitaes para os seus componentes-filhos.
56

Composite
Conseqncias
Referncias explcitas aos pais. Compartilhamento de componentes Maximizao da interface de Component

Padres Correlatos

57

Chain of Responsibility Decorator Flyweight Iterator Visitor

Decorator
Inteno
Agregar dinamicamente responsabilidades adicionais a um objeto.

Motivao
Existem situaes nas quais se deseja acrescentar responsabilidades a objetos individuais e no a toda uma classe. Exemplo: um toolkit para a construo de interfaces grficas deve permitir adicionar propriedades como bordas ou barras de rolagem. O uso de herana nesses casos inflexvel porque as novas propriedades precisam estar definidas em tempo de compilao.

Aplicabilidade
Deseja-se acrescentar responsabilidades a objetos de forma dinmica e transparente (ou seja, sem afetar outros objetos) Responsabilidades podem ser removidas ou alteradas Quando a extenso atravs de herana no prtica ou no possvel.

58

Decorator - Estrutura

59

Decorator Exemplo (1)

60

Decorator Exemplo (2)

aBorderDecorator component aScrollDecorator component aTextView component

61

Decorator
Colaboraes
Decorator repassa as solicitaes para o seu objeto Component. Opcionalmente pode executar operaes adicionais antes e depois de repassar a solicitao.

Conseqncias
Maior flexibilidade que herana esttica Evita classes sobrecarregadas de mtodos e atributos na raiz da hierarquia Um Decorator e seu Component no so idnticos. Grande quantidade de pequenos objetos

Padres Correlatos
Adapter, Composite, Strategy
62

Faade
Inteno
Fornecer uma interface unificada para um conjunto de interfaces de um subsistema. Definir uma interface de nvel mais alto que torna os subsistemas mais fceis de serem utilizados.

Motivao
Necessidade de estruturar um sistema em subsistema, facilitando o acesso e minimizando a comunicao e dependncias entre os subsistemas.
63

Faade
Aplicabilidade
Deseja-se fornecer uma interface simples e unificada para um sistema complexo. Deseja-se desacoplar os sub-sistemas dos clientes, promovendo-se a independncia e portabilidade dos subsistemas. Deseja-se estruturar o sistema em camadas.

64

Faade - Estrutura

65

Faade - Exemplo

66

Faade
Colaboraes
Os clientes se comunicam com os subsistemas atravs de solicitaes para Faade e este as repassa aos objetos apropriados. Os clientes que usam o sistema atravs de Faade no precisam acessar os objetos do subsistema diretamente.

Conseqncias
Isola os clientes dos subsistemas, tornando o sistema mais fcil de usar. Promove o acoplamento fraco entre o subsistema e seus clientes. Impede as aplicaes de usar diretamente as classes dos subsistemas.

Padres Correlatos
Abstract Factory, Mediator, Singleton

67

Flyweight
Inteno:
Usar compartilhamento para suportar eficientemente grandes quantidades de objeto de granularidade fina.

Motivao:
Existem situaes nas quais objetos se repetem em grandes quantidades, sendo que as diferenas de configurao entre eles so muito pequenas. uma situao comum em editores de texto.

Aplicabilidade
A aplicao utiliza um grande nmero de objetos Os custos de armazenamento so altos Os estados do objeto podem ser extrnsecos Muitos grupos de objetos podem ser substitudos por relativamente poucos objetos compartilhados A aplicao no depende da quantidade de objetos.

68

Flyweight - Estrutura

69

Flyweight - Estrutura
aFlyweightFactory
flyweights

aClient

flyweight pool

www.
aConcreteFlyweight IntrinsicState

aConcreteFlyweight IntrinsicState

70

Flyweight
Colaboraes
O estado que um flyweight necessita para funcionar deve ser caracterizado com o intrnseco ou extrnseco
Intrnseco: armazenado no objeto ConcreteFlyweight Extrnseco: armazenado o cliente e usado quando este invoca as operaes

Os clientes devem obter os objetos ConcreteFlyweight atravs do objeto FlyweightFactory para garantir que sejam compartilhados.

Consequncias
Reduo do nmero de instncias (compartilhamento) Reduo do nmero de estados intrnsecos por objeto

Padres Correlatos
Composite, State e Strategy

71

Proxy
Inteno
Fornecer um substituto ou marcador da localizao de outro objeto para controlar o acesso ao mesmo.

Motivao
Deseja-se adiar o custo da criao do objeto completo para quando ele seja realmente necessrio.
aTextDocument anImageProxy fmage fileName data anImage

72

Proxy - Estrutura

73

Proxy
Colaboraes
Proxy repassa as solicitaes para o RealSubject quando necessrio.

Consequncias
Um Proxy remoto pode ocultar o fato de que um objeto reside num espao de endereamento diferente. Um proxy virtual pode executar otimizaes como por exemplo a criao de objetos sob demanda. Proxies de proteo e smart references.

Padres relacionados
Adapter, Decorator
74

Padres Estruturais - discusso

Adapter x Bridge
Intenes
Adapter: focaliza a compatibilizao das interfaces Bridge: estabelece a ponte entre a abstrao e sua implementao.

Aplicveis a pontos diferentes do ciclo de vida do software

Adapter x Faade

Adapter: necessrio quando se deteta que necessrio compatibilizar interfaces diferentes, j implementadas. Bridge: no incio do projeto se descobre que uma abstrao pode ter implementaes diferentes.

Faade define uma nova interface Adapter adapta interfaces j existentes

75

Padres Estruturais - discusso

Composite x Decorator x Proxy
Composite e Decorator apresentam estruturas semelhantes. Composite: composio recursiva Decorator permite acrescentar responsabilidades a objetos sem usar subclasses. Composite estrutura as classes de forma que objetos compostos possam ser tratados de maneira uniforme. Composite e Decorator so frequentemente usados em conjunto. Decorator e Proxy tm estruturas similares: ambos descrevem uma forma de endereamento indireto para os objetos. Decorator e Proxy tm finalidades diferentes: Proxy no se preocupa em incluir novas funcionalidades.

76

Padres Comportamentais
Preocupam-se com algoritmos e atribuio de responsabilidades entre objetos. Descrevem tanto padres de objetos e classes e tambm padres de comunicao entre eles. Padres comportamentais de classes utilizam herana para distribuir o comportamento entre classes. Padres comportamentais de objetos utilizam composio em vez de herana para distribuir o comportamento entre objetos.
77

Chain of Responsability
Inteno
Evitar o acoplamento do remetente de uma solicitao ao seu receptor, dando a mais de um objeto a oportunidade de tratar uma solicitao. Encadear os objetos receptores passado a solicitao ao longo da cadeia at que um objeto a trate.
Situaes nas quais uma solicitao deve ser tratada por uma sequncia de receptores que s definida em tempo de execuo. Mais de um objeto pode tratar uma solicitao e o tratador no conhecido a priori. O conjunto de objetos que pode tratar a solicitao definido dinamicamente.

Motivao

Aplicabilidade

78

Chain of Responsability Estrutura

aClient aConcreteHandler aHandler successor successor aConcreteHandler

79

Chain of Responsability Estrutura

80

Chain of Responsability Exemplo

aSaveDialog handler

aPrintButton handler

anApplication handler aPrintDialog

anOkButton

handler

handler

81

Chain of Responsability
Colaboraes
Quando um cliente emite uma solicitao, esta se propaga ao longo da cadeia at que um objeto ConcreteHandler assuma a responsabilidade de tratlo.

Conseqncias
Acoplamento reduzido. Flexibilidade na atribuio de responsabilidades. A recepo no garantida.

Padres Correlatos
Composite
82

Command
Inteno
Encapsular uma solicitao como um objeto, permitindo parametrizar clientes com diferentes solicitaes, enfileirar ou fazer registro (log) de solicitaes e suportar operaes que podem ser desfeitas (undo).

Motivao
Existem situaes nas quais necessrio emitir solicitaes para objetos sem que se conhea nada a respeito da operao ou do receptor da mesma.

Aplicabilidade: situaes em que deseja-se

parametrizar as aes a serem execuadas pelos objetos (ao estilo callback em linguagem procedurais). especificar, enfileirar e executar solicitaes em tempos diferentes. registrar e eventualmente desfazer operaes realizadas estruturar um sistema com base em operaes de alto nvel construdas sobre operae bsicas.

83

Command - Estrutura

84

Command
Colaboraes
O cliente cria um objeto ConcreteCommand e especifica o seu receptor Um objeto Invoker armazena o objeto ConcreteCommand O Invoker emite uma solicitao chamando Execute no Command. Caso os comandos preciser ser desfeitos, ConcreteCommand armazena estados para desfazer o comando antes de invocar o mtodo execute(). O objeto ConcreteCommand invoca operaes no seu Receiver para executar a solicitao.
85

Command

86

Command
Conseqncias
Command desacopla o objeto que invoca a operao daquele que sabe como execut-la. Commands so objetos que podem ser manipulados e estendidos como qualquer outro objeto. possvel juntar comandos formando um comando composto (podendo-se usar o padro Composite). fcil acrescentar novos Commands porque no necessrio mudar classes existentes.

Padres Correlatos
Composite, Memento, Prototype
87

Interpreter
Inteno
Dada uma linguagem, interpretar sentenas nessas linguagens.

Motivao

Aplicabilidade: situaes tais que

Gramticas simples Eficincia no crtica.

Existem problemas que ocorrem com freqncia e para os quais possvel expressar suas instncias como sentenas de uma linguagem. Exemplos: pesquisa de padres em cadeias de caracteres (pattern matching) que podem ser descritos por expresses regulares.

88

Interpreter - Estrutura

89

Interpreter
Colaboraes
O cliente invoca a operao interpret() para uma rvore sinttica formada por instncias das subclasses de AbstractExpression. Os ns da rvore so interpretados recursivamente (cada n do tipo NonTerminalExpression invoca interpret() para os seus filhos). As operaes interpret() em cada n utilizam o contexto definido pelo cliente para armazenar e acessar o estado do interpretador.
90

Interpreter
Conseqncias
fcil implementar, alterar e estender gramticas simples. Gramticas complexas so difceis de manter. Pode se usar diferentes formas de interpretar as expresses

Padres correlatos

91

Composite Flyweight Iterator Visitor

Iterator
Inteno
Fornecer um meio de acessar sequencialmente os elementos de um objeto agregado, sem expor sua representao subjacente.

Motivao
Um agregado de objetos, assim como uma lista deve fornecer um meio de acessar seus elementos sem necessariamente expor sua estrutura interna. Pode ser necessrio percorrer um agregado de objetos de mais de uma maneira diferente. Eventualmente necessrio manter mais de um percurso pendente em um dado agregado de objetos.
92

Iterator
Aplicabilidade
Para acessar os contedo de um agregado de objetos sem expor a sua representao interna. Para suportar mltiplos percursos de agregados de objetos. Para fornecer uma interface uniforme que percorra diferentes estruturas agregadas (suportando iterao polimrfica).

93

Iterator - Estrutura

94

Iterator - Exemplo

95

Iterator
Colaboraes
Um objeto ConcreteIterator mantm o controle do objeto corrente no agregado de objeto e consegue definir o seu sucessor durante o percurso.

Conseqncias
Suporta variaes no percurso de um agregado. Iteradores simplificam a interface do agregado. Mais de um percurso pode estar em curso num mesmo agregado.

Padres correlatos
Composite, FactoryMethod, Memento.
96

Mediator
Inteno
Definir um objeto que encapsula a forma como um conjunto de objetos interage. Promove o acoplamento fraco entre os objetos ao evitar que os objetos explicitamente se refiram uns aos outros, permitindo que se varie independentemente as interaes.

Motivao
Em projetos orientados a objetos, normal distribuir o comportamento entre vrias classes. Isso pode resultar numa estrutura com muitas conexes entre os objetos e gera a necessidade de que cada objeto conhea os demais.
97

Mediator
aClient aListBox director director

aFontDialogDirector

aButton director

anEntryField director

98

Mediator

99

Mediator
Colaboraes
Colegas enviam e recebem solicitaes do objeto Mediator. O Mediator implementa o comportamento cooperativo pelo redirecionamento das solicitaes para os colegas apropriados.

Conseqencias
Limita o uso de subclasses Desacopla os colegas. Simplifica o protocolo dos objetos Abstrai a maneira como os objetos cooperam Centraliza o controle

Padres Correlatos
Faade, Observer

100

Memento
Inteno
Sem violar o encapsulamento, capturar e externalizar o estado interno de um objeto, de forma que este possa ser restaurado mais tarde. Algumas vezes necessrio registrar o estado interno de um objeto (checkpoints, undo). Um instantneo do estado de um objeto deve ser salvo para que possa ser restaurado mais tarde. Uma interface direta para acesso ao estado exporia detalhes de implementao do objeto, violando o encapsulamento.

Motivao

Aplicabilidade

101

Memento - Estrutura

102

Memento
Colaboraes
Um Caretaker (curador) solicita um memento de um originador, mantm o mesmo durante um tempo e quando necessrio, o devolve ao originador. Mementos so passivos. Somente o originador que o criou ir atribuir ou recuperar o seu estado.

Conseqncias
Preserva o encapsulamento. Simplifica o originador. Pode ser computacionalmente caro. Interfaces podem ser estreitas ou largas. Custos ocultos na custdia dos mementos.

Padres Correlatos
Command, Iterator

103

Observer
Inteno
Definir uma dependncia um para muitos entre objetos, de forma que quando um objeto muda de estado, todos os seus dependentes so notificados e atualizados.

Motivao
Ao se particiopar um sistema em uma coleo de classes cooperantes, muitas vezes necessrio manter a consistncia entre objetos relacionados. Isso deve ser feito preservando-se o acoplamento fraco para no comprometer a reusabilidade.

Aplicabilidade: em situaes tais que

Uma abstrao pode ser apresentada de vrias formas. A mudana de estado de um objeto mplica em mudanas em outros objetos. Um objeto deve ser capaz de notificar a outros objetos, sem necesriamente saber quem so esses objetos.

104

Observer - Estrutura

105

Observer
Colaboraes
O ConcreteSubject notifica seus observadores sempre que ocorrer uma mudana que poderia tornar inconsistente o estado deles com o seu prprio. Ao ser informado de uma mudana pelo ConcreteSubject um objeto Observer pode consult-lo para obter as informaes necessrias para atualizar o seu estado.
106

Observer
Conseqncias
Acoplamento abstrato entre Subject e Observer. Suporte a broadcast. Atualizaes inesperadas.

Padres Correlatos
Mediator Singleton
107

State
Inteno
Permite a um objeto alterar o seu comportamento em funo de alteraes no seu estado interno.

Motivao
Em muitas situaes o comportamento de um objeto deve mudar em funo de alteraes no seu estado.

Aplicabilidade
O comportamento de um objeto depende do seu estado e pode mudar em tempo de execuo. Operaes tm comandos condicionais grandes, com vrias alternativas que dependem do estado do objeto.
108

State um exemplo

109

State Estrutura

110

State
Colaboraes
O objeto Context delega solicitaes especficas de estados para o objeto ConcreteState corrente. Um objeto Context pode passar uma referncia a si prprio como um argumento para o objeto State acessar o seu contexto, se necessrio. Context a interface primria para os clientes. Clientes no necessitam tratar os objetos State diretamente. Tanto Context como as subclasses ConcreteState podem decidir a seqncia de estados.
111

State
Conseqncias
Confina comportamento especfico de estados e particiona o comportamento especfico para estados diferentes. Torna explcitas as transies de estado. Objetos State podem ser compartilhados, se no possuirem variveis de instncia. Nesse caso eles acabam implementando o padro Flyweight sem estado intrnseco.

Padres Relacionados
Flyweight, Singleton

112

Strategy
Inteno
Definir uma famlia de algoritmos, encapsular cada uma delas e torn-las intercambiveis. O padro Strategy permite que o algoritmo varie independentemente dos clientes que os utilizam.

Motivao
Numa mesma aplicao, para tratar certos tipos de problemas, diferentes algoritmos so apropriados em diferentes situaes. Novos algoritmos podem ser criados e incorporados a aplicao sem que esta tenha que sofrer alteraes estruturais.
113

Strategy - exemplo

114

Strategy - Estrutura

115

Strategy
Colaboraes
Strategy e Context interagem para implementar o algoritmo escolhido. Context repassa solicitaes dos seus clientes para a estratgia. Os clientes em geral passam um objeto ConcreteStrategy para o contexto.

Conseqncias
Famlias de algoritmos relacionados Alternativa para o uso de subclasses Eliminam comandos condicionais ao se codificar os mtodos

Padres Correlatos
Flyweight
116

Template Method
Inteno
Definir o esqueleto de um algoritmo, delegando determinados passos para as subclasses. Subclasses redefinem passos do algoritmo, sem alterar a estrutura geral do mesmo.

Motivao / Aplicabilidade
Famlias de aplicaes baseadas num framework podem necessitar de algoritmos genricos para determinadas funes, sendo que os detalhes de execuo do mesmo dependem da aplicao especfica.
117

Template Method - Estrutura

118

Template Method - exemplo

119

Template Method
Colaboraes
ConcreteClass depende de AbstractClass para implementar os passos invariantes do algoritmo.

Conseqncias
Tcnica fundamental para reuso de cdigo. Princpio de Hollywod: no nos chame, ns chamaremos voc.

Padres Correlatos
FactoryMethods, Strategy
120

Visitor
Inteno
Representar uma operao a ser implementada nos elementos de um agregado de objetos. Visitor permite implementar uma nova operao sem mudar as classes dos elementos que constituem os agregados.

Motivao / Aplicabilidade
Em algumas situaes necessrio percorrer um agregado de objetos realizando operaes sobre seus elementos e dependendo do caso, o conjunto de operaes independe das classes dos objetos que constituem o agregado.
121

Visitor - exemplo

122

Visitor Estrutura(1)

123

Visitor Estrutura(2)

124

Visitor
Colaboraes
Um cliente que usa o padro Visitor deve criar um objeto ConcreteVisitor e percorrer a esrutura do objeto, visitando cada elemento atravs desse Visitor. Torna fcil a adio de novas operaes. Um visitante rene operaes relacionadas e separa as operaes no relacionadas. difcil acrescentar novas classes ConcreteElement. Compromete o encapsulamento.

Conseqncias

Padres Correlatos

Composite, Interpreter

125

Padres de Projeto Concluses

Vocabulrio comum de projeto
Para comunicar, documentar e explorar alternativas de projeto. Tornam um sistema menos complexo ao permitir que se fale sobre ele num nvel mais alto de abstrao. Elevam o nvel no qual se projeta e se discute o projeto.

Auxlio para a documentao e aprendizado

Facilita a compreenso de sistemas existentes. Ao fornecer solues para problemas comuns, acelera o processo de aprendizado.
126

Padres de Projeto Concluses

Complementam o processo de desenvolvimento
Mostram como usar tcnicas bsicas e tambm como parametrizar um sistema. Auxiliam a evoluir do modelo de anlise para o modelo de implementao.

Apoio na refatorao
Ajudam a definir como reorganizar um projeto. Reduzem o esforo de uma futura refatorao do projeto.
127