Profa.

Thienne Johnson

E. Gamma and R. Helm and R. Johnson and J.

Vlissides. Design Patterns - Elements of
Reusable Object-Oriented Software. AddisonWesley, 1995.
Conhecido como GoF (Gang of Four)
Verso em portugus disponvel na biblioteca da EACH.
(nome: Padres de Projeto)

Java Design Patterns At a Glance

http://www.javacamp.org/designPattern

Java Design Patterns Resource Center

http://www.deitel.com/ResourceCenters/Programming/
JavaDesignPatterns/tabid/1103/Default.aspx

Projetar software para reso difcil porque

deve-se procurar por:
Uma boa decomposio do problema e a
abstrao correta.
Flexibilidade, modularidade e elegncia.

Projetos freqentemente emergem de um

processo iterativo (tentativas e muitos
erros).

A boa notcia que bons projetos existem:

na verdade, eles apresentam caractersticas
recorrentes,
mas eles quase nunca so idnticos.

Perspectiva de engenharia: os projetos

podem ser descritos, codificados ou
padronizados?
isto iria diminuir a fase de tentativa e erro.
sofwares melhores seriam produzidos mais
rpidos.
4

Tambm conhecidos como

Padres de Desenho de Software OO

ou simplesmente como Padres.

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

Muitos. Um site relata ao menos 250 PP. E

muito mais so criados a cada dia.
PP no so idiomas, algortimos ou
componentes.

Para criar um sistema, podem ser necessrios

vrios padres.
Diferentes designers podem usar diferentes
padres para resolver o mesmo problema.
Geralmente:

Alguns padres se encaixam naturalmente

Um padro pode levar a outro
Alguns padres so similares e alternativos
Padres podem ser descobertos e documentados
Padres no so mtodos ou frameworks
Padres do uma dica para resolver um problema de
forma efetiva

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

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 e listas
ligadas, passamos a falar de coisas de muito
mais alto nvel como Fbricas, Fachadas,
Observador, Estratgia, etc.
10

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
CC fosse maior. E o impacto foi enorme, o
livro vendeu centenas de milhares de
cpias.
11

Todo padro inclui

Nome
Problema
Soluo
Conseqncias / Foras
Existem outros tipos de padres mas vamos nos
concentrar no GoF.
12

1. Nome (inclui nmero da pgina)

um bom nome essencial para que o padro caia
na boca do povo

2. Objetivo / Inteno

3. Tambm Conhecido Como

4. Motivao
um cenrio mostrando o problema e a
necessidade da soluo

5. Aplicabilidade
como reconhecer as situaes nas quais o padro
aplicvel
13

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

7. Participantes
as classes e objetos que participam e quais so suas
responsabilidades

8. Colaboraes
como os participantes colaboram para exercer as suas
responsabilidades
14

9. Conseqncias
vantagens e desvantagens, trade-offs

10.Implementao
com quais detalhes devemos nos preocupar quando
implementamos o padro
aspectos especficos de cada linguagem

11.Exemplo de Cdigo
no caso do GoF, em C++ (a maioria) ou Smalltalk

15

12.Usos Conhecidos
exemplos de sistemas reais de domnios
diferentes onde o padro utilizado

13.Padres Relacionados
quais outros padres devem ser usados em
conjunto com esse
quais padres so similares a este, quais so as
dierenas

16

Categorias de Padres do GoF

Padres de Criao
Padres Estruturais
Padres Comportamentais

17

Processo de criao de Objetos

Abstract Factory
Builder
Factory Method
Prototype
Singleton

18

Composio de classes ou objetos

Adapter
Bridge
Composite
Decorator
Faade
Flyweight
Proxy

19

Forma na qual classes ou objetos interagem e distribuem

responsabilidades

Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento

Observer
State
Strategy
Template Method
Visitor

20

Propsito

Criao

Escopo

Estrutural

Comportamental

Classe

Factory Method (121)

Adapter (157)

Interpreter (274)
Template Method (360)

Objeto

Abstract Factory (99)

Builder (110)
Prototype (133)
Singleton (144)

Adapter (157)
Bridge (171)
Composite (183)
Decorator (196)
Facade (208)
Flyweight (218)
Proxy (233)

Chain of Responsibility
(251)
Command (263)
Iterator (289)
Mediator (305)
Memento (316)
Observer (326)
State (338)
Strategy (349)
Visitor (366)

EscopoClasse negociam relaionamentos entre classes e sub-classes. Essas

relaes so estabelecidas atravs de herana. Ento so estticas fixas em
tempo de compilao.

Escopo Objeto negociam com relaes de objetos, que podem mudar em

tempo de execuo.

http://mahemoff.com/paper/software/learni
ngGoFPatterns/
Fcil
Intermedirio
Avanado

1.
2.
3.
4.
5.

6.
7.
8.
9.
10.
11.
12.

Facade (185)
Singleton (127)
Mediator (273)
Iterator (257)
Strategy (315)
Command (233)
Builder (97)
State (305)
Template Method (325)
Factory Method (107)
Memento (283)
Prototype (117)

1.
2.
3.

4.
5.

Proxy (207)
Decorator (175)
Adapter (139)
Bridge (151)
Observer (293)

1.
2.
3.
4.
5.

Composite (163)
Interpreter (243)
Chain Of Responsibility (223)
Abstract Factory (87)
Visitor (331)

Prov uma interface unificada para um

conjunto de interfaces em um subsistema.
Define uma interface de mais alto nvel que
torna mais fcil o uso do subsistema.

Oferece uma interface simples para um

subsistema complexo
Existem muitas dependncias entre clientes e
as classes de implementao de uma
abstrao.
A introduo de um "Faade" ir desacoplar o
subsistema dos clientes dos outros subsistemas,
promovendo assim, a independncia e
portabilidade desses subsistemas.

 Quando se deseja subsistemas em camadas.

Quando se quer definir um ponto de entrada para
cada nvel do subsistema.
Se os subsistemas so dependentes, ento pode-se
simplificar a dependncia entre eles fazendo com que
eles se comuniquem uns com os outros unicamente
atravs dos seus "Faades.

Abstract Factory (99)

Mediator (305)
Singletons (144).

AccountService

User

createAccount()

deposit()
withdraw()
TransactionService
Faade

addTransaction()
createAccount()
deposit()
withdraw()
addTransaction()
applyForLoan()

LoanService

applyForLoan()

public class BankFaade {

private AccountService accountService;
private TransactionService transactionService;
private LoanService loanService;

public addAccount(Account account) {

accountService.addAccount(account);
}
public deposit(int accountId, float amount) {
accountService.deposit(accountId, amount);
}
public withdraw(int accountId, float amount) {
accountService.withdraw(accountId, amount);
}
public addTransaction(Transaction tx) {
transactionService.addTransaction(tx);
}
public applyForLoan(Customer cust, LoanDetails loan) {
loanService.apply(cust, loan);
}

//FORA
public class Power {
public void connect() {
System.out.println("The power is connected.");
}
public void disconnect() {
System.out.println("The power is disconnected.");
}
}
// PLACAME
public class MainBoard {
public void on() {
System.out.println("The mainboard is on.");
}
public void off() {
System.out.println("The mainboard is off.");
}
}

//HDD HardDisk
public class HardDisk {
public void run() {
System.out.println("The harddisk is running.");
}
public void stop() {
System.out.println("The harddisk is stopped.");
}
}
// Sistema Operacional
public class OperationSystem {
public void startup() {
System.out.println("The opertion system is startup.");
}
public void shutdown() {
System.out.println("The operation system is shutdown.");
}
}

Faade para Test Computer

public class Computer {

private Power power;
private MainBoard board;
private HardDisk disk;
private OperationSystem system;
public Computer(Power power, MainBoard board, HardDisk disk, OperationSystem system) {
this.power = power;
this.board = board;
this.disk = disk;
this.system = system;
}
public void startup() {
this.power.connect();
this.board.on();

this.disk.run();
this.system.startup();
}
public void shutdown() {
this.system.shutdown();
this.disk.stop();
this.board.off();
this.power.disconnect();
}
}

Usando o Faade para ligar e desligar o computador

public class TestComputer {

public static void main(String[] args) {
Power power = new Power();
MainBoard board = new MainBoard();
HardDisk disk = new HardDisk();
OperationSystem system = new OperationSystem();
Computer computer = new Computer(power, board, disk, system);
computer.startup();
computer.shutdown();
}
}

Facades e a Lei de Demeter (No fale com

estranhos)
A figura mostra algumas classes que podem
ser usadas em um sistema de segurana.
Use o PP Faade para facilitar o acesso direto
do cliente aos elemento.

Garantir que apenas um objeto exista,

independente do nmero de requisies que
receber para cri-lo

Aplicaes
Um nico banco de dados
1 spooler de impresso
Um nico acesso ao arquivo de log
Um nico objeto que representa um vdeo
Uma nica fachada (Faade)

Objetivo: garantir que uma classe s tenha uma

instncia

Uma varivel global mantm um objeto

acessvel, mas no impede instanciar
mltiplos objetos
Soluo: fazer a prpria classe
ser responsvel por criar somente 1 instncia dela
prpria.
garantir que nenhuma outra instncia seja criada

Participantes
Define uma operao getInstance() que permite que
clientes acessem sua instncia nica
um mtodo esttico (class method)
Pode ser responsvel pela criao de sua instncia
nica

Colaboraes
Clientes acessam a instncia apenas atravs da
operao getInstance() do Singleton

Vrios benefcios existem:

O Singleton tem controle sobre como e quando clientes

acessam a instncia
Apenas a implementao interna do Singleton precisa
mudar
Mais flexvel que mtodos estticos
Embora possa parecer que podemos fazer o equivalente a
um Singleton com mtodos estticos, lembre que isso no
permitiria o polimorfismo:
NomeDeClasse.xpto(); // chamada no polimrfica
// ... versus ...
Config conf = Config.getInstance();
conf.xpto(); // essa chamada polimrfica

Uma forma de no permitir chamadas ao

construtor
A nica instncia uma instncia normal de uma
classe, mas a classe escrita de forma que s 1
instncia possa ser criada.
O construtor protegido.
O cliente que tenta instanciar o Singleton diretamente
obter um erro em tempo de compilao.

Esconder a operao de criao de instncia atrs

de uma operao de classe (usando uma funo
esttica ou mtodo de classe)

Essa operao tem acesso varivel que armazena

a nica instncia, e garante que a varivel
inicializada com a nica instncia antes de retornar
o valor.

Garante que somente 1 instncia criada e inicializada

antes do primeiro uso.

 With lazy instantiation, a program refrains from

creating certain resources until the resource is first

needed -- freeing valuable memory space.

if (instance == null) {
instance = new Singleton();
}
return instance;

public class Singleton {

private static Singleton instance; // own instance
/* protected to enable controlled subclassing */
protected Singleton() {}

public static Singleton getInstance() {

// 'lazy' evaluate instance

if (instance == null) {
instance = new Singleton();
}
return instance;

public void operation() {

System.out.println("Singleton.operation() executing" );
}
}

public class SingletonTest {

private static SingletonTest referencia;
private SingletonTest() {
// TODO: Cdigo do construtor aqui.
}

public static SingletonTest getInstance() {

if (referencia == null)
referencia = new SingletonTest();
return referencia;
}

public class Clone {

public static void main(String args[]) throws Exception {
SingletonTest teste = SingletonTest.getInstance();
SingletonTest clone = (SingletonObject)teste.clone();
}
}

Abstract Factory
Builder
Prototype