Padres GoF

Leonardo Gresta Paulino Murta

leomurta@ic.uff.br
 Agenda
Introduo
Padres de Criao
Padres de Estrutura
Padres de comportamento

Leonardo Murta Padres GoF 2

 Introduo
Os padres GoF (Gamma et al., 1994) formam um catlogo de boas
decises de projeto
Este catlogo dividido em trs tipos de padres:
Padres de criao: preocupam-se em como criar objetos
Padres de estrutura: preocupam-se em como compor objetos
Padres de comportamento: preocupam-se em como os
objetos devem interagir

Leonardo Murta Padres GoF 3

 Introduo
Os padres GoF refletem situaes muito recorrentes em projeto
OO, e podem ser vistos como o mnimo que todo projetista OO
deveria saber
Neste catlogo tambm est descrita a estrutura de documentao
de um padro e como os padres se relacionam
Existem vrios outros catlogos de padres
Esses catlogos relatam padres em diferentes nveis de abstrao: anlise,
arquitetura, projeto e codificao (idioma)

Leonardo Murta Padres GoF 4

Leonardo Murta Padres GoF 5
 Padro Abstract Factory
Objetivo:
Fornecer uma interface para criao de objetos relacionados sem
especificar as suas classes concretas
Motivao:
Suponha que se deseja fazer um sistema de janelas independente de
SO (Motif, Windows, ...)
Seria necessrio definir os widgets de forma abstrata e especializar
para cada SO
Alm disso, seria necessrio definir uma fbrica genrica de widgets e
especializar para os SOs

Leonardo Murta Padres GoF 6

 Padro Abstract Factory

Leonardo Murta Padres GoF 7

 Padro Builder
Objetivo:
Separar a construo de objetos complexos da sua
representao de forma que o mesmo processo de construo
possa criar diferentes representaes
Motivao:
Suponha que se deseje converter documentos RTF para outros
formatos (texto, HTML, ...)
Seria necessrio verificar quais partes um documento pode ter
e definir uma especializao para cada uma das partes
Leonardo Murta Padres GoF 8
 Padro Builder

Leonardo Murta Padres GoF 9

 Padro Factory Method
Objetivo:
Definir uma interface de criao de objetos mas deixar as
subclasses decidirem qual objeto criar
Motivao:
Na construo de frameworks, no possvel, a priori,
determinar qual elemento deve ser criado
A soluo permitir que o instanciador do framework faa a
criao de uma instncia especfica

Leonardo Murta Padres GoF 10

 Padro Factory Method

Leonardo Murta Padres GoF 11

 Padro Prototype
Objetivo:
Especificar tipos de objetos a serem criados usando prottipos
e aplicando clonagem nesses prottipos
Motivao:
Existem situaes onde desejvel utilizar um objeto modelo
complexo para a criao de outros objetos
Supondo o caso de uma ferramenta de desenho, pode ser til
criar estruturas complexas e fazer uso delas como base para
outros desenhos mais complexos
Leonardo Murta Padres GoF 12
 Padro Prototype

Leonardo Murta Padres GoF 13

 Padro Singleton
Objetivo:
Assegurar que uma determinada classe tem somente uma
instncia e fornecer um ponto global de acesso a ela
Motivao:
Em quase todo tipo de sistema existem classes com uma nica
instncia
Em um sistema operacional, existe a necessidade de
representar o spool de impressoras

Leonardo Murta Padres GoF 14

 Padro Singleton

Leonardo Murta Padres GoF 15

Leonardo Murta Padres GoF 16
 Padro Adapter
Objetivo:
Converter a interface de uma classe em outra, para atender as
expectativas do cliente
Motivao:
Permitir que classes incompatveis trabalhem em conjunto
possvel utilizar um wrapper para conectar o sistema de PDV
com o servio de autorizao de carto, mesmo que os mtodos
no sejam 100% compatveis

Leonardo Murta Padres GoF 17

 Padro Adapter

Leonardo Murta Padres GoF 18

 Padro Bridge
Objetivo:
Desacoplar a abstrao da sua implementao, de modo que
ambos possam variar independentemente
Motivao:
Supondo que um sistema de locadora de automveis deseje
representar categorias e modelos de carro
Ser que CarroGM deve herdar de Carro? E CarroEconomico?
CarroGM uma implementao de Carro

Leonardo Murta Padres GoF 19

 Padro Bridge

Leonardo Murta Padres GoF 20

 Padro Composite
Objetivo:
Compor objetos utilizando uma estrutura de rvore para
representar hierarquias de todo-parte
Motivao:
Permitir que objetos do tipo todo ou do tipo parte sejam
tratados da mesma maneira
No projeto de um sistema de arquivos, espera-se que tanto um
arquivo quanto um diretrio possam informar o seu tamanho

Leonardo Murta Padres GoF 21

 Padro Composite

Leonardo Murta Padres GoF 22

 Padro Decorator
Objetivo:
Atribuir responsabilidades adicionais a um objeto de forma
dinmica
Motivao:
Em algumas situaes desejado que um objeto tenha mais
responsabilidades que os demais da sua classe
Supondo um sistema de janelas, possvel desejar que uma
determinada caixa de texto tenha borda, e que outra tenha
barra de rolagem
Leonardo Murta Padres GoF 23
 Padro Decorator

Leonardo Murta Padres GoF 24

 Padro Facade
Objetivo:
Prover uma interface nica para um conjunto de interfaces de
um subsistema, facilitando o seu uso
Motivao:
Existem situaes onde um conjunto de classes deve se
comportar como um componente
Para isso, o cliente deve falar com uma nica interface
Suponha a interao entre um sistema cliente com um sistema
de controle de biblioteca
Leonardo Murta Padres GoF 25
 Padro Facade

Leonardo Murta Padres GoF 26

 Padro Flyweight
Objetivo:
Utilizar compartilhamento para atender a um grande nmero
de objetos
Motivao:
Regularmente, objetos com contedos idnticos so criados em
um sistema (para representar a mesma entidade)
Em um sistema de RH, o objeto que representa a formao dos
funcionrios pode estar sendo repetido

Leonardo Murta Padres GoF 27

 Padro Flyweight

Leonardo Murta Padres GoF 28

 Padro Proxy
Objetivo:
Fornece um substituto a um objeto (procurador)
Motivao:
Em situaes onde custoso o acesso direto a um objeto (rede,
disco, etc.), pode-se utilizar um representante local
Em um sistema operacional, necessrio fornecer acesso a
sistemas de arquivos remotos (ex.: NFS)

Leonardo Murta Padres GoF 29

 Padro Proxy

Leonardo Murta Padres GoF 30

Leonardo Murta Padres GoF 31
 Padro Chain of Responsability
Objetivo:
Desacoplar o objeto que envia uma requisio de um receptor
nico
Motivao:
Permitir que mais de um objeto possa tratar uma requisio
Em um sistema com ajuda (help) sensvel ao contexto, os
componentes que no tm texto associado podem repassar a
responsabilidade para os seus containers

Leonardo Murta Padres GoF 32

 Padro Chain of Responsability

Leonardo Murta Padres GoF 33

 Padro Command
Objetivo:
Encapsular comandos em objetos para permitir utilizao em
lote ou undo dos mesmos
Motivao:
Em um sistema de edio de texto desejvel que seja possvel
desfazer uma ou mais aes efetuadas
Tambm desejvel que o editor possa funcionar de forma no
interativa, atravs de um roteiro (script) de comandos

Leonardo Murta Padres GoF 34

 Padro Command

Leonardo Murta Padres GoF 35

 Padro Interpreter
Objetivo:
Definir uma representao em objetos de uma determinada
linguagem
Motivao:
Em um sistema que lida com expresses lgicas, interessante
a criao de uma linguagem que facilite a sua utilizao
Por exemplo, uma expresso (Ex) pode ser representada por um
Booleano, Not(Ex), And(Ex, Ex), Or(Ex, Ex)

Leonardo Murta Padres GoF 36

 Padro Interpreter

Leonardo Murta Padres GoF 37

 Padro Iterator
Objetivo:
Fornece um mecanismo de acesso a elementos de uma
agregao sem quebrar o encapsulamento
Motivao:
Se um objeto de Turma fornecer a sua lista de alunos interna,
podero ser removidos ou inseridos alunos sem o
conhecimento da Turma
Esse tipo de problema ocorre com freqncia, e visto como
uma quebra de encapsulamento
Leonardo Murta Padres GoF 38
 Padro Iterator

Leonardo Murta Padres GoF 39

 Padro Mediator
Objetivo:
Definir um objeto que encapsula como vrios outros objetos
interagem
Motivao:
Promover acoplamento fraco no permitindo que os objetos se
referenciem
Em um sistema de informao, um Mediator pode ser utilizado para
manter a consistncia da interface
Ex.: habilitar ou desabilitar opes em funo da seleo de outras
opes

Leonardo Murta Padres GoF 40

 Padro Mediator

Leonardo Murta Padres GoF 41

 Padro Memento
Objetivo:
Capturar e externalizar o estado interno de um objeto sem
quebrar o encapsulamento
Motivao:
Permitir a implementao de mecanismos de checkpoint em um
sistema para possibilitar undo
til em situaes que o padro Command no funciona
Em um processamento numrico longo, podem ser salvos
estados intermedirios
Leonardo Murta Padres GoF 42
 Padro Memento

Leonardo Murta Padres GoF 43

 Padro Observer
Objetivo:
Definir uma dependncia de um para muitos com um
mecanismo de notificao de eventos
Motivao:
A mesma informao (modelo) pode ser exibida em diferentes
formatos (viso) em paralelo
Suponhamos que dados estatsticos devem ser exibidos, ao
mesmo tempo, em forma de tabela e grfico
Esses dados podem ser alterados durante a exibio
Leonardo Murta Padres GoF 44
 Padro Observer

Leonardo Murta Padres GoF 45

 Padro State
Objetivo:
Permitir que um objeto modifique o seu comportamento em
funo do seu estado interno
Motivao:
Gerar o efeito de uma troca de tipo de um objeto em tempo de
execuo
Um forno de microondas deve se comportar de formas
diferentes em funo do seu estado quando o boto de ligar
pressionado
Leonardo Murta Padres GoF 46
 Padro State

Leonardo Murta Padres GoF 47

 Padro Strategy
Objetivo:
Definir uma famlia de algoritmos de forma encapsulada
Motivao:
Alguns algoritmos se repetem com freqncia, por isso devem
ser isolados para facilitar a manuteno
Tanto os objetos da classe CatalogoHospedes quanto os objetos
da classe CatalogoServicos de um sistema de controle de hotis
precisam de algoritmos de ordenao

Leonardo Murta Padres GoF 48

 Padro Strategy

Leonardo Murta Padres GoF 49

 Padro Template Method
Objetivo:
Definir o esqueleto de um algoritmo e delegar alguns dos seus
passos para as subclasses
Motivao:
Na construo de frameworks necessrio especificar o
comportamento global e definir algumas lacunas para serem
preenchidas no momento da instanciao
Em um framework de validao de usurio, a forma de validar
pode ser SGBD, LDAP, arquivo, etc.
Leonardo Murta Padres GoF 50
 Padro Template Method

Leonardo Murta Padres GoF 51

 Padro Visitor
Objetivo:
Aumentar a coeso das classes isolando em outras classes
tarefas pouco coesas
Motivao:
Em uma ferramenta Case deve ser possvel gerar as informaes
de casos de uso e classes em HTML, PDF, RTF, TeX, etc.
Entretanto, no desejvel que a classe que representa um
caso de uso tenha mtodos para cada tipo de gerao

Leonardo Murta Padres GoF 52

 Padro Visitor

Leonardo Murta Padres GoF 53

 Bibliografia
Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J.;
Design Pattern Elements of Reusable Object-
Oriented Software; Addison-Wesley; 1994

Leonardo Murta Padres GoF 54

 Padres GoF

Leonardo Gresta Paulino Murta

leomurta@ic.uff.br