Padres de Projeto de Software

Orientado a Objetos

Ricardo Argenton Ramos

[Baseado nos slides do professor Fabio Kon - USP]

Padres de Projeto de Software OO

Tambm conhecidos como




Padres de Desenho de Software OO

ou simplesmente como Padres.

A Inspirao

A idia de padres foi apresentada por

Christopher Alexander em 1977 no contexto
de Arquitetura (de prdios e cidades):
Cada padro descreve um problema que
ocorre repetidamente de novo e de novo em
nosso ambiente, e ento descreve a parte
central da soluo para aquele problema de
uma forma que voc pode usar esta soluo
um
milho
de
vezes,
sem
nunca
implementa-la duas vezes da mesma forma.
3

Catlogo de solues

Um padro encerra o conhecimento de uma

pessoa muito experiente em um determinado
assunto de uma forma que este
conhecimento pode ser transmitido para
outras pessoas menos experientes.
Outras cincias (p.ex. qumica) e engenharias
possuem catlogos de solues.
Desde 1995, o desenvolvimento de software
passou a ter o seu primeiro catlogo de
solues para projeto de software: o livro
GoF.
4

Gang of Four (GoF)

E. Gamma and R. Helm

and R. Johnson and J.
Vlissides. Design Patterns
- Elements of Reusable
Object-Oriented
Software. AddisonWesley, 1995.

Gang of Four (GoF)

Passamos a ter um vocabulrio comum para

conversar sobre projetos de software.
Solues que no tinham nome passam a ter
nome.
Ao invs de discutirmos um sistema em termos
de pilhas, filas, rvores, passamos a falar de
coisas de muito mais alto nvel como Fbricas,
Fachadas, Observador, Estratgia, etc.
A maioria dos autores eram entusiastas de
Smalltalk, principalmente o Ralph Johnson.
Mas acabaram baseando o livro em C++ para
que o impacto junto comunidade de C fosse
maior. E o impacto foi enorme, o livro vendeu
centenas de milhares de cpias.
6

O Formato de um padro

Todo padro inclui o mnimo:







Nome
Problema
Soluo
Conseqncias / Foras
Exemplo

O Formato dos padres no GoF 1/4






Nome (inclui nmero da pgina)

um bom nome essencial para que o padro
caia na boca do povo
Objetivo / Inteno
Motivao

um cenrio mostrando o problema e a
necessidade da soluo
Aplicabilidade

como reconhecer as situaes nas quais o
padro aplicvel

O Formato dos padres no GoF 2/4



Estrutura

uma representao grfica da estrutura de
classes do padro (usando OMT91) em, s
vezes, diagramas de interao (Booch 94)
Participantes

as classes e objetos que participam e quais
so suas responsabilidades
Colaboraes

como os participantes colaboram para
exercer as suas responsabilidades

O Formato dos padres no GoF 3/4



Conseqncias

vantagens e desvantagens, trade-offs
Implementao

com quais detalhes devemos nos preocupar
quando implementamos o padro

aspectos especficos de cada linguagem
Exemplo de Cdigo

no caso do GoF, em C++ (a maioria) ou
Smalltalk

10

O Formato dos padres no GoF 4/4



Usos Conhecidos

exemplos de sistemas reais de domnios
diferentes onde o padro utilizado
Padres Relacionados

quais outros padres devem ser usados em
conjunto com esse

quais padres so similares a este, quais
so as dierenas

11

Tipos de Padres de Projeto

Categorias de Padres do GoF





Padres de Criao
Padres Estruturais
Padres Comportamentais

Exemplo:


Fbrica Abstrata (Abstract Factory (87))

- padro de Criao de objetos

12

Fbrica Abstrata
Abstract Factory (87)

Objetivo:

prover uma interface para criao
de famlias de objetos relacionados
sem especificar sua classe concreta.

13

Abstract Factory

- Motivao

Considere uma aplicao com interface grfica que

implementada para plataformas diferentes (Motif para
UNIX e outros ambientes para Windows e MacOS).
As classes implementando os elementos grficos no
podem ser definidas estaticamente no cdigo.
Precisamos de uma implementao diferente para cada
ambiente. At em um mesmo ambiente, gostaramos de
dar a opo ao usurio de implementar diferentes
aparncias (look-and-feels).
Podemos solucionar este problema definindo uma classe
abstrata para cada elemento grfico e utilizando
diferentes implementaes para cada aparncia ou para
cada ambiente.
Ao invs de criarmos as classes concretas com o
operador new, utilizamos uma Fbrica Abstrata para
criar os objetos em tempo de execuo.
O cdigo cliente no sabe qual classe concreta
utilizamos.
14

Abstract Factory -

Aplicabilidade

Use uma fbrica abstrata quando:

um sistema deve ser independente da
forma como seus produtos so criados
e representados;

um sistema deve poder lidar com uma
famlia de vrios produtos diferentes;

voc quer prover uma biblioteca de
classes de produtos mas no quer
revelar as suas implementaes, quer
revelar apenas suas interfaces.
15

Abstract Factory -

Estrutura

AbstractFactory

Client

CreatProductA()
CreatProductB()

AbstractProductA

ProductA2
ConcreteFactory1

ConcreteFactory2

CreatProductA()

CreatProductA()

CreatProductB()

CreatProductB()

ProductA1

AbstractProductB

ProductB2

ProductB1
16

Abstract Factory

Participantes

AbstractFactory (WidgetFactory)
ConcreteFactory (MotifWidgetFactory,
WindowsWidgetFactory)
AbstractProduct (Window, ScrollBar)
ConcreteProduct (MotifWindow,
MotifScrollBar, WindowsWindow,
WindowsScrollBar)
Client - usa apenas as interfaces declaradas
pela AbstractFactory e pelas classes
AbstratProduct
17

Abstract Factory -

Colaboraes

Normalmente, apenas uma instncia de

ConcreteFactory criada em tempo de
execuo.

Esta instncia cria objetos atravs das classes

ConcreteProduct correspondentes a uma
famlia de produtos.

Uma AbstractFactory deixa a criao de

objetos para as suas subclasses
ConcreteFactory.
18

Abstract Factory -

Conseqncias

O padro
1.
isola as classes concretas dos clientes;
2.
facilita a troca de famlias de produtos
(basta trocar uma linha do cdigo pois a
criao da fbrica concreta aparece em um
nico ponto do programa);
3.
promove a consistncia de produtos (no
h o perigo de misturar objetos de famlias
diferentes);
4.
dificulta a criao de novos produtos
ligeiramente diferentes (pois temos que
modificar a fbrica abstrata e todas as
fbricas concretas).
19

Abstract Factory 1.
2.

3.

Implementao

Fbricas abstratas em geral so implementadas

como (127).
Na fbrica abstrata, cria-se um mtodo fbrica
para cada tipo de produto. Cada fbrica concreta
implementa o cdigo que cria os objetos de fato.
Se tivermos muitas famlias de produtos, teramos
um excesso de classes fbricas concretas.
Para resolver este problema, podemos usar o
Prototype (117): criamos um dicionrio mapeando
tipos de produtos em instncias prototpicas destes
produtos.
Ento, sempre que precisarmos criar um novo
produto pedimos sua instncia prototpica que
crie um clone (usando um mtodo como clone() ou
copy()).
20

Abstract Factory 4.

5.

Implementao

Em linguagens dinmicas como Smalltalk onde

classes so objetos de primeira classe, no
precisamos guardar uma instncia prototpica,
guardamos uma referncia para a prpria
classe e da utilizamos o mtodo new para
construir as novas instncias.
Definindo fbricas extensveis.
normalmente, cada tipo de produto tem o seu prprio
mtodo fbrica; isso torna a incluso de novos produtos
difcil.
soluo: usar apenas um mtodo fbrica

Product make (string thingToBeMade)

isso aumenta a flexibilidade mas torna o cdigo menos
seguro (no teremos verificao de tipos pelo
21
compilador).

Abstract Factory

Usos Conhecidos

InterViews usa fbricas abstratas para

encapsular diferentes tipos de aparncias para
sua interface grfica
ET++ usa fbricas abstratas para permitir a
fcil portabilidade para diferentes ambientes de
janelas (XWindows e SunView, por exemplo)
Sistema de captura e reproduo de vdeo feito
na UIUC usa fbricas abstratas para permitir
portabilidade entre diferentes placas de captura
de vdeo.
Em linguagens dinmicas como Smalltalk (e
talvez em POO em geral) classes podem ser
vistas como fbricas de objetos.
22

Abstract Factory -

Padres Relacionados

Fbricas abstratas so normalmente

implementadas com mtodos fbrica
(FactoryMethod (107)) mas podem tambm ser
implementados usando Prototype (117).
O uso de prottipos particularmente
importante em linguagens no dinmicas como
C++ e em linguagens "semi-dinmicas" como
Java.
Em Smalltalk, no to relevante.
 Curiosidade: a linguagem Self no possui
classes, toda criao de objetos feita via
clonagem.
Uma fbrica concreta normalmente um
Singleton (127)
23

Os 23 Padres do GoF

Criao

Abstract Factory
Builder
Factory Method
Prototype
Singleton

24

Os 23 Padres do GoF

Estruturais

Adapter
Bridge
Composite
Decorator
Faade
Flyweight
Proxy

25

Os 23 Padres do GoF

Comportamentais

Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento

Observer
State
Strategy
Template Method
Visitor

26

Prxima aula

Em grupos de 3 alunos devero

estudar um tipo de padro do Gof e
apresentar em sala de aula para os
outros.

27

Recapitulando

Voltando ao Christopher Alexander:

Cada padro descreve um problema que
ocorre repetidamente de novo e de novo
em nosso ambiente, e ento descreve a
parte central da soluo para aquele
problema de uma forma que voc pode
usar esta soluo um milho de vezes,
sem nunca implement-la duas vezes da
mesma forma.

28