Padrões de Projeto

Prévia do material em texto

Conceitos básicos de OO
• Um objeto empacota tanto dados quanto procedimentos
• Os procedimentos são chamados de operações cuja a implementação corresponde 
ao método.
• Um objeto executa um método quando ele recebe uma mensagem de um cliente
• As operações são a única maneira de mudar o estado de um objeto.
• Assinatura da operação corresponde ao nome da operação, aos objetos que ela 
aceita como parâmentro e o valor retornado.
• Um Tipo é o nome usado para uma interface específica.
• Uma interface modela um comportamento esperado. Se comporta como uma 
classe que contenha apenas métodos abstratos. 
Conceitos básicos de OO
• Quando dizemos que um objeto é do tipo Janela, significa que ele aceita todas 
as as solicitações para as operações definidas na interface janela.
• Um objeto pode ter muitos tipos, asssim como diferentes objetos podem 
compartilhar do mesmo tipo.
• Parte de um objeto pode ser caracterizada por um tipo, e outras partes por 
outros tipos.
• Dizemos que um tipo é um subtipo de outro se sua interface contem a 
interface do supertipo.
• A interface de um objeto não indica nada sobre a sua implementação. Pode-se 
ter dois objetos que tenham implementações diferentes podem ter interfaces 
idênticas.
Conceitos básicos de OO
public interface Pesado { 
 double obterPeso(); 
} 
 
public interface Colorido { 
 Color obterCor(); 
} 
 
public class Porco extends Animal implements Pesado, Colorido { 
 public void fazerBarulho() { 
 System.out.println("Óinc!"); 
 } 
 
 // Implementação da interface Pesado 
 public double obterPeso() { 
 return 50.00; 
 } 
 
 // Implementação da interface Colorido 
 public Color obterCor() { 
 return Color.BLACK; 
 } 
 
 // Uma propriedade só do porco 
 public boolean enlameado() { 
 return true; 
 } 
} 
 
Conceitos básicos de OO
• Polimofirmos corresponde a capacidade de dois objetos diferentes 
responderem de forma diferente a uma mesma mensagem.
• Uma implementação de um objeto é definida por sua classe.
• Os objetos são criados por instanciação de uma classe.
• Uma flecha tracejada indica que uma classe instancia objetos de outra 
classe
• Uma classe abstrada é uma classe que tem como principal objetivo definir 
uma interface comum para as suas subclasses. Neste caso ela não pode 
ser instanciada e as operações que não implementa são chamada de 
operações abstratas.
Conceitos básicos de OO
• Diferenças entre classe de um objeto e seu tipo.
– A classe de um objeto define como ele é implementado. A classe define o 
estado interno do objeto e a implementação de suas operações. Já o tipo se 
refere somente a sua interface, isto é, ao conjunto de solicitações que ele 
pode responder. 
– Um objeto pode ter muitos tipos, e objetos de diferentes classes podem ter o 
mesmo tipo.
– Quando dizemos que um objeto é uma instância de uma classe, isto significa 
que dizer que o objeto suporte a interface definida pela classe.
– Herança pura de interface significa herdar publicamente de classes abstratas 
puras.
Conceitos básicos de OO
Programar para uma interface e não para uma implementação: Todas as 
subclasses podem responder a solicitações na interface da classe abstrata, 
tornado-se todas, subtipo desta.
Vantangens:
• Os clientes permanecem sem conhecimento dos tipos específicos dos 
objetos que eles usam;
• Os clientes permanecem sem conhecimento das classes que 
implementam estes objetos. 
• Os clientes somente tem conhecimento das classes abstratas que definem 
a interface.
Desta forma não se deve declarar variáveis como instâncias de classes 
concretas específicas e sim prende-las somente a uma interface definida por 
uma classe abstrata.
Conceitos básicos de OO
Herança versus Composição
• A reutilização por meio de subclasse é chamada de reutilização de caixa 
branca, já que as subclasses tem visibilidade para os métodos da 
superclasse. Sua definição é definida estaticamente, é mais simples de se 
utilizar e mais facil de modificar a implementação que esta sendo 
reutilizada.
• A reutilização por meio de composição é chamada de reutilzação de caixa 
preta, por que os detalhes internos dos objetos não ficam visíveis. 
Implementações podem ser modificadas em tempo de execução, já que 
pode-se trocar o objeto deste tenham o mesmo tipo, além de não ficar tão 
amarrada a implementação da sua superclasse.
• Uma linha cheia indica que um objeto de uma classe mantém uma 
referência para a instância de outra classe.
Conceitos básicos de OO
• Principais aplicações de padrões de projeto
• Toolkits – conjunto de classes relacionadas e reutilizáveis, projetadas para oferecer 
funcionalidades úteis e de finalidade geral. Ex. Classes coleções para manipular listas, 
conjuntos e pilhas. Os toolkits não impõe um projeto específico, simplesmente fornecem 
funcionalidades para auxilar aplicações.
• Frameworks – é um conjunto de classes que cooperam para a construção de um software de 
uma determinada categoria. Ex. Contrução de compiladores, site de venda etc.
• Neste caso a customização se dá através da criação de classes específicas para a aplicação, 
derivadas de classes abstratas do framework. Nesta caso, o framework dita a arquitetura da 
aplicação.
• Um framework enfatiza a reutilização do projeto em relação a reutilização do código. Quando 
se utiliza um framework você reutiliza o corpo principal e escreve o código que este chama. 
Desta forma pode-se escrever aplicações mais rapidamente e com estrutruras similares. Por 
outro lado fica-se preso as decisões de projeto já tomadas pelo framework.
Conceitos básicos de OO
• Principais aplicações de padrões de projeto
• Toolkits – conjunto de classes relacionadas e reutilizáveis, projetadas para oferecer 
funcionalidades úteis e de finalidade geral. Ex. Classes coleções para manipular listas, 
conjuntos e pilhas. Os toolkits não impõe um projeto específico, simplesmente fornecem 
funcionalidades para auxilar aplicações.
• Frameworks – é um conjunto de classes que cooperam para a construção de um software de 
uma determinada categoria. Ex. Contrução de compiladores, site de venda etc.
• Neste caso a customização se dá através da criação de classes específicas para a aplicação, 
derivadas de classes abstratas do framework. Nesta caso, o framework dita a arquitetura da 
aplicação.
• Um framework enfatiza a reutilização do projeto em relação a reutilização do código. Quando 
se utiliza um framework você reutiliza o corpo principal e escreve o código que este chama. 
Desta forma pode-se escrever aplicações mais rapidamente e com estrutruras similares. Por 
outro lado fica-se preso as decisões de projeto já tomadas pelo framework.
10
Design Patterns
• Ao longo dos anos, os melhores programadores catalogaram soluções de projeto 
que eram comuns a problemas específicos no projeto de software orientado a 
objetos
• Essas soluções ficaram conhecidas como Padrões de Projeto (Design Patterns).
• O conceito de Padrões de Projeto foi proposto por Christopher Alexander 
(arquiteto) no final dos anos 70 para o projeto de edificações e cidades.
• “Cada padrão descreve um problema que ocorre freqüentemente e então 
descreve o cerne da solução para aquele problema, de maneira que você pode 
utilizar essa solução milhares de vezes em situações diferentes”
11
Design Patterns
• O conceito de Design Pattens ganhou grande importância após a publicação do 
livro Design Patterns: Elements of Reusable Object-Oriented Software em 1995
• Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides são conhecidos como 
“Gang of Four”.
• Definições para Object Oriented Design Patterns
– São micro-arquiteturas que definem colaborações entreclasses e objetos
– Definem soluções simples e elegantes para problemas específicos no 
projeto de software orientado a objetos
– Reutilização de idéias, não de código
– São frutos da experiência dos melhores projetistas OO 
12
Design Patterns
• Design Patterns não são concebidos a partir das primeiras soluções para 
um determinado problema.
• São produtos de várias revisões de projeto e código que tinham como 
principal objetivo reutilização e flexibilidade.
• Por que utilizar Design Patterns ?
– Eles foram testados
– Eles são reutilizáveis
– Eles provêem um vocabulário comum de soluções que pode ser 
utilizado para expressar grandes soluções de forma sucinta
13
Design Patterns
• Os Design Patterns possuem quatro elementos essenciais que os descrevem:
– Um Nome 
– O Problema
– A Solução
– As Conseqüências
14
Design Patterns
• Um Nome
– Representa uma maneira simples de descrever um problema de projeto, sua 
solução e conseqüências em uma ou duas palavras
– Facilita a comunicação e documentação
– Atualmente, os nomes dos Design Patterns são equivalentes aos nomes de 
estruturas de dados conhecidas: fila, pilha, lista.
• O Problema
– Descreve quando aplicar o padrão 
– Explica o problema e o seu contexto
– Algumas vezes, o problema descreve pré-condições que devem existir para 
aplicação do padrão
15
Design Patterns
• A Solução
– Descreve os elementos constituintes do projeto, seus relacionamentos, 
responsabilidades, e colaborações
– A solução não descreve um projeto concreto ou implementação particular 
porque um padrão é apenas um modelo que pode ser utilizado em diversas 
situações
• As Consequências
– Descrevem os resultados e trade-offs da aplicação dos padrões
Padrões GoF - Criação
propósito:
• Abstraem o processo de instanciação. Ajudam a tornar um sistema 
independente de como os seus objetos são criados, compostos e 
representados.
• Utiliza herença para variar a classe que é instanciada enquanto que um 
padrão de criação de objetos delegará a instanciação para outro objeto.
• Encapsulam conhecimento das classes concretas que são usadas pelo 
sistema.
• ocutam o modo de como as instancias destas classes são criadas.
Padrões GoF de Criação - FACTORY METHOD
Propósito
• O padrão Factory Method é caracterizado por retornar uma instância 
dentre muitas possíveis classes, dependendo dos dados providos a ele.
• Definir uma Interface para criar objetos de forma a deixar subclasses 
decidirem qual classe instanciar
Padrões GoF de Criação - FACTORY METHOD
Aplicabilidade
• Quando uma classe não pode antecipar a classe dos objetos que precisa criar
• Quando uma classe quer que as suas subclasses especifiquem os objetos 
criados
• Quando classes delegam responsabilidade para uma de várias classes de apoio 
e queremos localizar num ponto único o conhecimento de qual subclasse está 
sendo utilizada
Exemplo:
• Carro é a classe base (pai) e as classes Vectra, Omega, Gol e Golf derivam dela (filhas).
• A classe CarroFactory é a classe Factory que decide qual das subclasses retornar
• O método getCarro() é o método de Factory que recebe um parâmetro (tipo) e retorna 
uma instância da classe Carro
Padrões GoF de Criação - FACTORY METHOD
• public class Golf extends Carro { 
• public Golf() { 
• valor = 35000.0f; 
• } 
• } 
•
• public class Gol extends Carro { 
• public Gol() { 
• valor = 20000.0f; 
• } 
• } 
•
• public abstract class Carro { 
• protected float valor; 
•
• public float getPreco() { 
• return valor; 
• } 
• } 
•
• public class Vectra extends Carro
{ 
• public Vectra() { 
• valor = 30000.0f; 
• } 
• } 
•
• public class Omega extends Carro
{ 
• public Omega() { 
• valor = 50000.0f; 
• } 
• } 
Padrões GoF de Criação - FACTORY METHOD
• public class CarroFactory { 
• public static Carro getCarro( String tipoCarro ) { 
• if( tipoCarro == null ) return null; 
• else if( tipoCarro.equals("Vectra") ) return new Vectra(); 
• else if( tipoCarro.equals("Omega") ) return new Omega(); 
• else if( tipoCarro.equals("Golf") ) return new Golf(); 
• else if( tipoCarro.equals("Gol") ) return new Gol(); 
• else return null; 
• } 
• } 
• public class FactoryExample { 
• public static void main( String args[] ) { 
• //parâmetro passado como argumento no console 
• //pega a instância do tipo do carro 
• Carro carro = CarroFactory.getCarro( args[0] ); 
• //mostra o valor 
• if( carro != null ) { 
• System.out.println( "Preço: " + carro.getPreco() ); 
• } 
• } 
Padrões GoF de Criação - ABSTRACT FACTORY METHOD
• Está a um nível de abstração maior do que o padrão Factory Method. 
• Antes de instanciar o objeto, é necessário instanciar a sua fábrica de objetos que retorna 
uma das várias fábricas.
Exemplo:
sistema precisa de suporte a múltiplos tipos de interfaces gráficas, como Windows, Motif ou 
MacIntosh. 
Ao sinalizar ao factory o tipo de interface a ser utilizada, ele retorna a fábrica GUI que retorna 
os objetos relativos ao tipo.
Quando for requisitado um objeto específico como um botão, check-boxes e janelas, a fábrica 
de GUI retorna as instâncias desses componentes para o Windows.
Padrões GoF de Criação - ABSTRACT FACTORY METHOD
Padrões GoF de Criação - ABSTRACT FACTORY METHOD
public abstract class Fabricante { 
protected String name; 
public abstract Carro getCarro( String marca ); 
public static Fabricante getInstance( String fabricante ) { 
if( fabricante == null ) { 
return null; 
} 
else if(fabricante.equals("Chevrolet")) { 
return new Chevrolet(); 
} 
else if(fabricante.equals("Volkswagen")) { 
return new Volkswagen(); 
} 
else { 
return null; 
} 
} 
} 
public class Chevrolet extends Fabricante { 
public Chevrolet() { 
name = "Chevrolet"; 
} 
public Carro getCarro( String marca ) { 
if( marca == null ) { 
return null; 
} 
else if( marca.equals("Vectra") ) { 
return new Vectra(); 
} 
else if( marca.equals("Omega") ) { 
return new Omega(); 
} 
else { 
return null; 
} 
} 
} 
Padrões GoF de Criação - ABSTRACT FACTORY METHOD
public class Volkswagen extends Fabricante { 
public Volkswagen() { 
name = "Volkswagen"; 
} 
public Carro getCarro( String marca ) { 
if( marca == null ) { 
return null; 
} 
else if( marca.equals("Gol") ) { 
return new Gol(); 
} 
else if( marca.equals("Golf") ) { 
return new Golf(); 
} 
else { 
return null; 
} 
} 
} 
public class AbstractFactoryExample {
public static void main( String args[] ) {
//parâmetro passado como argumento no console
//pega a instância do fabricante
Fabricante fab = Fabricante.getInstance( args[0] );
//pega a instância do carro, de acordo com o fabricante
Carro carro = fab.getCarro( args[1] );
//mostra o valor
if( carro != null ) {
System.out.println( "Preço: " + Carro.getPreco() );
}
}
}
Padrões GoF de Criação - ABSTRACT FACTORY METHOD
Observações:
Normalmente uma única instância da classe Concrete Factory é instanciada.
vantagens:
• Isola as classes concretas. Clientes manipulam as instâncias através da interfaces abstratas.
• Nomes das classes-produto ficam isolados na implementação da fábrica concreta. Ela pode 
utilizar diferentes configurações de produto simplesmente trocando a fábrica concreta.
• Permite que se utilize todos os objetos de uma família de cada vez.
• Uma fábrica concreta especificará seus produtos redefinindo metodo fábrica para cada um.
• Abstract Factory somente declara somente uma interface para criação de produtos. Fica a 
cargodas ConcreteProducts criá-los efetivamente
Padrões GoF de Criação - Builder
Propósito
Separar a construção de um objeto complexo de sua representação para criar representações 
diferentes com o mesmo processo.
director — constrói um objeto utilizando a interface do builder;
builder — especifica uma interface para um construtor de partes do objeto-produto;
concrete builder — define uma implementação da interface builder, mantém a 
representação que cria e fornece interface para recuperação do produto;
product — o objeto complexo acabado de construir. Inclui classes que definem as partes 
constituintes.
Padrões GoF de Criação - Builder
Exemplo:
O padrão Builder pode ser utilizado em uma aplicação que converte o formato RTF
para uma série de outros formatos e que permite a inclusão de suporte para 
conversão para outros formatos, sem a alteração do código fonte do leitor de RTF.
Padrões GoF de Criação - Builder
abstract class ConversorTexto { 
public void converterCaractere(char c) { // vazio } 
public void converterParagrafo() { // vazio } 
public void converterFonte(Fonte f) { // vazio } 
}
class ConversorPDF extends ConversorTexto { 
public void converterCaractere(char c) { System.out.print("Caractere PDF"); } 
public void converterParagrafo() { System.out.print("Parágrafo PDF"); } 
public void converterFonte(Fonte f) { System.out.print("Fonte PDF"); } 
} 
class ConversorTeX extends ConversorTexto { 
public void converterCaractere(char c) { System.out.print("Caractere Tex"); } 
public void converterParagrafo() { System.out.print("Paragrafo Tex"); } 
public void converterFonte(Fonte f) { System.out.print("Fonte Tex"); } 
}
class ConversorASCII extends ConversorTexto { 
public void converterCaractere(char c) { System.out.print("Caractere ASCII"); } 
}
Padrões GoF de Criação - Builder
class LeitorRTF { 
private ConversorTexto conversor; 
LeitorRTF(ConversorTexto c) { this.conversor = c; } 
public void lerRTF() { 
List<Token> tokens = obterTokensDoTexto(); 
for (Token t : tokens) { 
if (t.getTipo() == Token.Tipo.CARACTERE) { 
conversor.converterCaractere(t.getCaractere());} 
if (t.getTipo() == Token.Tipo.PARAGRAFO) { 
conversor.converterParagrafo(); } 
if (t.getTipo() == Token.Tipo.FONTE) { 
conversor.converterFonte(t.getFonte()); }
}
}
} 
public class Cliente { 
public static void main(String[] args) { 
ConversorTexto conversor; 
if (args[0].equals("pdf")) { 
conversor = new ConversorPDF(); 
} else if (args[0].equals("tex")) { 
conversor = new ConversorTeX(); 
} else { 
conversor = new ConversorASCII(); 
} 
LeitorRTF leitor = new LeitorRTF(conversor); 
leitor.lerRTF(); 
} 
}
Padrões GoF de Criação - Builder
BUIDER Comparado ao Abstract Factory
Ambos podem ser utilizados para a construção de objetos complexos. 
A principal diferença entre eles é que o Builder constrói objetos complexos passo 
a passo e o Abstract Factory constrói famílias de objetos, simples ou complexos, 
de uma só vez.
Padrões GoF de Criação - Singleton
Propósito 
Garantir que uma classe tenha apenas uma única instância e fornecer um ponto de acesso 
centralizado a ela.
Exemplo
Um sistema pode ter apenas um gerenciador de janelas, ou gerenciador de impressão, ou 
então um único ponto de acesso ao banco de dados.
Como fazer
• A maneira de se fazer uma classe que possua uma única instância dela mesma é utilizar 
uma variável estática na classe, onde será guardada a referência para a instância 
corrente.
• No caso do Singleton, a classe dever ter um construtor private, ou seja, ela não poderá 
ser instanciada diretamente.
• Cada vez que esse método for chamado, ele deve checar se já existe uma instância da 
classe e retorná-la
• caso contrário ele deve instanciar a classe, guardar a referência ao objeto no atributo 
estático da classe e então retorná-lo.
Padrões GoF de Criação - Singleton
public class DBConnectionPool { 
private static DBConnectionPool instance; 
private DBConnectionPool() { 
// cria conexões para o banco de dados 
} 
public synchronized static DBConnectionPool getInstance() { 
if( instance == null ) { 
instance = new DBConnectionPool(); 
} 
return instance; 
} 
public Connection getConnection() { 
Connection conn = null; 
//pega uma conexão livre ou uma nova conexão 
return conn; 
} 
public void releaseConnection( Connection conn ) { 
//libera a conexão de volta pro pool 
} 
} 
Padrões GoF de Criação - Prototype
Objetivo: 
O padrão Prototype tem como objetivo criar objetos específicos a 
partir da instância de um protótipo. Isso permite criar novos objetos 
através da cópia deste protótipo.
Padrões GoF de Criação - Prototype
Estrutura
1. Client – solicita a um protótipo a criação de uma cópia de si mesmo, 
gerando outro objeto.
2. Prototype – especifica uma interface para clonar a si próprio.
3. Concrete Prototype – implementa uma operação para clonar a si 
próprio
Padrões GoF de Criação - Prototype
Utilização
• Sistemas que possuem componentes cujo estado inicial possui poucas 
variações e onde é conveniente disponibilizar um conjunto pré-
estabelecido de protótipos que dão origem aos objetos que compõem o 
sistema.
Vantagens
• Criação de novos objetos através da variação de valores. 
• Poder aproveitar o estado existente de um objeto.
Padrões GoF de Criação - Prototype
public abstract class CarroPrototype {
protected double valorCompra;
public abstract String exibirInfo();
public abstract CarroPrototype clonar();
public double getValorCompra() {
return valorCompra;
}
public void setValorCompra(double valorCompra) {
this.valorCompra = valorCompra;
}
}
public class FiestaPrototype extends CarroPrototype {
protected FiestaPrototype(FiestaPrototype fiestaPrototype) {
this.valorCompra = fiestaPrototype.getValorCompra();
}
public FiestaPrototype() {
valorCompra = 0.0;
}
@Override
public String exibirInfo() {
return "Modelo: Fiesta\nMontadora: Ford\n" + "Valor: R$"
+ getValorCompra();
}
@Override
public CarroPrototype clonar() {
return new FiestaPrototype(this);
}
}
public static void main(String[] args) {
FiestaPrototype prototipoFiesta = new FiestaPrototype();
CarroPrototype fiestaNovo = prototipoFiesta.clonar();
fiestaNovo.setValorCompra(27900.0);
CarroPrototype fiestaUsado = prototipoFiesta.clonar();
fiestaUsado.setValorCompra(21000.0);
System.out.println(fiestaNovo.exibirInfo());
System.out.println(fiestaUsado.exibirInfo());
}
Padrões GoF - Estruturais 
• Tem como objetivo estabelecer soluções para que classes e objetos possam 
formar estruturas maiores.
 ADAPTER
 COMPOSITE
 FACADE
 DECORATE
 BRIDGE
 FLYWEIGHT
 PROXY
• Classificação
Classe e Objeto
• Propósito
 Converte a interface de uma classe em outra interface, esperada pelos 
clientes.
 Permite que classes com interfaces incompatíveis trabalhem em 
conjunto
• Motivação
• Algumas vezes, uma classe de um toolkit não é reutilizada porque sua 
interface não corresponde a uma interface requerida por uma aplicação 
específica
Padrões GoF Estruturais - ADAPTER 
• Meu sistema já possui classes implementadas e testadas (Cliente A e
Coelce) que agora devem se comunicar.
• Entretanto Cliente A requer uma interface diferente da classe Coelce, que
não pode ser modificada
Padrões GoF Estruturais - ADAPTER 
Classe Adapter• Usa herança múltipla (ou implementação de interface)
• Client: colabora com objetos compatíveis com a interface de Target
• Target: define interface específica do domínio
• Adaptee: define interface existente que requer adaptação
• Adapter: adapta a interface de Adaptee à interface de Target
Padrões GoF Estruturais - ADAPTER 
Energia getEnergiaEm110V(){
Return c.getEnergiaEm220V();
}
Padrões GoF Estruturais - ADAPTER 
Classe Adapter - solução
• Adaptador de classes - consequências:
•Utiliza uma classe concreta para adaptar Adaptee a Target
•Permite sobrescrever algum comportamento de Adaptee, pois Adapter
é subclasse de Adaptee
Padrões GoF Estruturais - ADAPTER 
Objeto Adapter
•Usa composição de objetos
• Client: chama operações em uma 
instância de Adapter
•Adapter: chama operações de Adaptee
que executa a solicitação
Padrões GoF Estruturais - ADAPTER 
• Adaptador de objetos - consequências:
•Permite que um único Adapter trabalhe com 
muitos Adaptees (Adapter e suas subclasses)
•Adapter pode acrescentar novas funcionalidades a 
todos os Adaptees de uma só vez
•É mais difícil redefinir um comportamento de 
Adaptee, pois é necessário criar e referenciar 
subclasses de Adaptee
Padrões GoF Estruturais - ADAPTER 
• Classificação
 Estrutural de Objeto
• Propósito
 Anexar responsabilidades adicionais a um objeto dinamicamente
 Decorators oferecem uma alternativa flexível ao uso de herança para 
estender uma funcionalidade
• Também conhecido como
• Wrapper
Padrões GoF Estruturais - DECORATOR 
I- Como fazer para calcular a conta? 
Bill
+beverages+calculateBill()
II- Se acrescentássemos 
os topos (leite, chocolate, chantilly)? 
Padrões GoF Estruturais - DECORATOR 
Excelente!
Padrões GoF Estruturais - DECORATOR 
Motivação:
Em algumas situações o uso de hierarquias para descrever comportamento 
pode causar combinações exponenciais 
• Herança não resolve sempre!
Aplicabilidade:
• Para adicionar responsabilidades a objetos dinamicamente e 
transparentemente, ou seja, sem afetar outro objeto
• Quando não é possível estender subclasses 
• Às vezes, um grande número de extensões independentes, são possíveis 
mas podem causar uma explosão de subclasses para suportar todas as 
combinações
Padrões GoF Estruturais - DECORATOR 
Participantes:
•Component
 define a interface para objetos que podem ter responsabilidades 
acrescentadas a eles dinamicamente
• ConcreteComponent
 define um objeto para o qual responsabilidades adicionais podem ser 
atribuídas
•Decorator
 mantém uma referência para um objeto Component e define uma 
interface que segue a interface de Component
•ConcretDecorator
 acrescenta responsabilidades ao componente
Padrões GoF Estruturais - DECORATOR 
Padrões GoF Estruturais - DECORATOR 
Como funciona 
o método cost()?
Padrões GoF Estruturais - DECORATOR 
Cálculo do custo
Padrões GoF Estruturais - DECORATOR 
Exemplo de código
Imagine uma aplicação para montagens de veículos. O cliente irá escolher o 
veículo desejado na aplicação e será redirecionado a outra página em que 
poderá escolher que produtos gostaria de adicionar no veículo, como ar 
condicionado e trava elétrica, e dessa forma simular o preço final do veículo 
escolhido.
Padrões GoF Estruturais - DECORATOR 
Padrões GoF Estruturais - DECORATOR 
public interface Carro {
public double getCusto();
public String getDescricao();
public String getProdutos();
}
Padrões GoF Estruturais - DECORATOR 
public abstract class CarroDecorator implements Carro{
protected Carro carroDecorado;
public CarroDecorator(Carro CarroDecorator) {
this.carroDecorado = CarroDecorator;
}
@Override
public double getCusto() {
return carroDecorado.getCusto();
}
@Override
public String getDescricao() {
return carroDecorado.getDescricao();
}
@Override
public String getProdutos() {
return carroDecorado.getProdutos();
}
}
Padrões GoF Estruturais - DECORATOR 
public class CarroComArCondicionado extends CarroDecorator{
private double custo;
private String produtos;
public CarroComArCondicionado(Carro CarroDecorator) {
super(CarroDecorator);
this.custo = 900.00;
this.produtos = "Ar Condicionado";
}
@Override
public double getCusto() {
return super.getCusto() + custo;
}
@Override
public String getDescricao() {
return super.getDescricao();
}
@Override
public String getProdutos() {
return super.getProdutos() + ", "+ produtos;
}
}
Padrões GoF Estruturais - DECORATOR 
public class CarroComTravaEletrica extends CarroDecorator {
private double custo;
private String produtos;
public CarroComTravaEletrica(Carro CarroDecorator) {
super(CarroDecorator);
this.custo = 400.00;
this.produtos = "Trava Elétrica";
}
@Override
public double getCusto() {
return super.getCusto() + custo;
}
@Override
public String getDescricao() {
return super.getDescricao();
}
@Override
public String getProdutos() {
return super.getProdutos() + ", "+ produtos;
}
}
Padrões GoF Estruturais - DECORATOR 
public class CrossFox implements Carro{
private double custo = 40000.00;
private String produto = "Cross Fox 1.6";
private String descricao = " Novo carro da WV com cambio automático";
@Override
public double getCusto() {
return custo;
}
@Override
public String getDescricao() {
return descricao;
}
@Override
public String getProdutos() {
return produto;
}
}
Padrões GoF Estruturais - DECORATOR 
public class Main {
public static void main(String[] args) {
Carro carro = new CrossFox();
System.out.println("Produto: " + carro.getProdutos());
System.out.println("Preço: R$ " + carro.getCusto());
// Adiconando Ar e Travas
carro = new CarroComArCondicionado(carro);
carro = new CarroComTravaEletrica(carro); 
System.out.println("Produto: " + carro.getProdutos());
System.out.println("Preço: R$ " + carro.getCusto());
}
}
Padrões GoF de Estruturais - DECORATOR 
Padrões GoF de Estruturais - COMPOSITE 
"Compor objetos em estruturas de árvore para representar hierarquias 
todo-parte. Composite permite que clientes tratem objetos individuais e 
composições de objetos de maneira uniforme.” 
Exemplo : uniformizar o acesso aos arquivos e pastas.
A ideia do Composite é criar uma classe base que contém toda a interface 
necessária para todos os elementos e criar um elemento especial que 
agrega outros elementos. 
Padrões GoF de Estruturais - COMPOSITE 
A classe base Arquivo implementa todos os métodos 
necessários para arquivos e pastas.
Padrões GoF Estruturais - COMPOSITE 
public abstract class ArquivoComponent {
String nomeDoArquivo;
public void printNomeDoArquivo() {
System.out.println(this.nomeDoArquivo);
}
public String getNomeDoArquivo() {
return this.nomeDoArquivo;
}
public void adicionar(ArquivoComponent novoArquivo) throws Exception {
throw new Exception("Não pode inserir arquivos em: "
+ this.nomeDoArquivo + " - Não é uma pasta");
}
public void remover(String nomeDoArquivo) throws Exception {
throw new Exception("Não pode remover arquivos em: "
+ this.nomeDoArquivo + " -Não é uma pasta");
}
public ArquivoComponent getArquivo(String nomeDoArquivo) throws Exception {
throw new Exception("Não pode pesquisar arquivos em: "
+ this.nomeDoArquivo + " - Não é uma pasta");
}
}
Padrões GoF Estruturais - COMPOSITE 
public class ArquivoVideo extends ArquivoComponent {
public ArquivoVideo(String nomeDoArquivo) {
this.nomeDoArquivo = nomeDoArquivo;
}
}
na classe que representa a Pasta é necessário sobrescrever o 
comportamento padrão e repassar a chamada para todos os arquivos, 
sejam arquivos ou pastas.
para criar um arquivo de vídeo por exemplo, bastaimplementar o 
construtor:
Padrões GoF de Estruturais - COMPOSITE 
public class ArquivoComposite extends ArquivoComponent {
ArrayList<ArquivoComponent> arquivos = new ArrayList<ArquivoComponent>();
public ArquivoComposite(String nomeDoArquivo) {
this.nomeDoArquivo = nomeDoArquivo;}
@Override public void printNomeDoArquivo() {
System.out.println(this.nomeDoArquivo);
for (ArquivoComponent arquivoTmp : arquivos) {
arquivoTmp.printNomeDoArquivo();
}
}
@Override public void adicionar(ArquivoComponent novoArquivo) {
this.arquivos.add(novoArquivo);
}
@Override public void remover(String nomeDoArquivo) throws Exception {
for (ArquivoComponent arquivoTmp : arquivos) {
if (arquivoTmp.getNomeDoArquivo() == nomeDoArquivo) {
this.arquivos.remove(arquivoTmp);
return;
}
}
throw new Exception("Não existe este arquivo");
}
@Override public ArquivoComponent getArquivo(String nomeDoArquivo) throws Exception {
for (ArquivoComponent arquivoTmp : arquivos) {
if (arquivoTmp.getNomeDoArquivo() == nomeDoArquivo) {
return arquivoTmp;
}
}
throw new Exception("Não existe este arquivo");
}
}
Padrões GoF de Estruturais - COMPOSITE 
public static void main(String[] args) {
ArquivoComponent minhaPasta = new ArquivoComposite("Minha Pasta/");
ArquivoComponent meuVideo = new ArquivoVideo("meu video.avi");
ArquivoComponent meuOutroVideo = new ArquivoVideo("serieS01E01.mkv");
minhaPasta.adicionar(meuVideo);
minhaPasta.adicionar(meuOutroVideo);
minhaPasta.printNomeDoArquivo();
minhaPasta.getArquivo(meuVideo.getNomeDoArquivo())
minhaPasta.remover(meuVideo.getNomeDoArquivo());
minhaPasta.printNomeDoArquivo();
}
Padrões GoF de Estruturais - Facade
Objetivo:
• Fornecer uma interface unificada para um conjunto de interfaces em um 
subsistema.
• Esta interface de nivel mais alto permite uma maior facilidade na utilização do 
subsistema
Motivação:
• Estruturar um sistema em subsistemas ajuda a reduzir a complexidade. Um 
objetivo comum de projetos é minimizar a comunicação e as dependências entre 
subsistemas
Padrões GoF de Estruturais - Facade
Padrões GoF de Estruturais - Facade
/* Partes complexas */
class CPU {
public void freeze() { ... }
public void jump(long position) { ... }
public void executar() { ... }
}
class Memoria {
public void load(long position, byte[] data) { ... }
}
class HardDrive {
public byte[] read(long lba, int tamanho) { ... }
}
/* Façade */
class Computador {
private CPU cpu;
private Memoria memoria;
private HardDrive hardDrive;
public Computador() {
this.cpu = new CPU();
this.memoria = new Memoria();
this.hardDrive = new HardDrive();
}
public void ligarComputador() {
cpu.freeze();
memory.load(BOOT_ADDRESS, hardDrive.read(BOOT_SECTOR, SECTOR_SIZE));
cpu.jump(BOOT_ADDRESS);
cpu.executar();
}
}
Padrões GoF de Estruturais - Facade
/* Client */
class Voce {
public static void main(String[] args) {
Computador facade = new Computador();
facade.ligarComputador();
}
}
Padrões GoF de Estruturais - Bridge 
Objetivo: 
• “Desacoplar uma abstração da sua implementação, de modo que as duas 
possam variar independentemente.” 
• A intenção do padrão Bridge é desacoplar um conjunto de 
implementações do conjunto de objetos que as utilizam. 
Padrões GoF de Estruturais - Bridge 
Estrutura:
Padrões GoF de Estruturais - Bridge 
Quando utilizar:
Deve ser utilizado quando for necessário evitar ligação permanente entre a 
interface e a implementação, para que alterações não afetem os clientes.
Padrões GoF de Estruturais - Bridge 
Exemplo: 
public interface JanelaImplementada {
void desenharJanela(String titulo);
void desenharBotao(String titulo);
}
public class JanelaWindows implements JanelaImplementada {
@Override
public void desenharJanela(String titulo) {
System.out.println(titulo + " - Janela Windows");
}
@Override
public void desenharBotao(String titulo) {
System.out.println(titulo + " - Botão Windows");
}
}
Padrões GoF de Estruturais - Bridge 
Exemplo: 
public abstract class JanelaAbstrata {
02
03 protected JanelaImplementada janela;
04
05 public JanelaAbstrata(JanelaImplementada j) {
06 janela = j;
07 }
08
09 public void desenharJanela(String titulo) {
10 janela.desenharJanela(titulo);
11 }
12
13 public void desenharBotao(String titulo) {
14 janela.desenharBotao(titulo);
15 }
16
17 public abstract void desenhar();
18
19 }
Padrões GoF de Estruturais - Bridge 
public class JanelaDialogo extends JanelaAbstrata {
public JanelaDialogo(JanelaImplementada j) {
super(j);
}
@Override public void desenhar() {
desenharJanela("Janela de Diálogo");
desenharBotao("Botão Sim");
desenharBotao("Botão Não");
desenharBotao("Botão Cancelar");
}
}
public class JanelaDialogo extends JanelaAbstrata {
public JanelaDialogo(JanelaImplementada j) {
super(j);
}
@Override public void desenhar() {
desenharJanela("Janela de Diálogo");
desenharBotao("Botão Sim");
desenharBotao("Botão Não");
desenharBotao("Botão Cancelar");
}
}
Padrões GoF de Estruturais - Bridge 
public static void main(String[] args) {
JanelaAbstrata janela = new JanelaDialogo(new JanelaLinux());
janela.desenhar();
janela = new JanelaAviso(new JanelaLinux());
janela.desenhar();
janela = new JanelaDialogo(new JanelaWindows());
janela.desenhar();
}
Padrões GoF de Estruturais - Flyweight
Objetivo
• É utilizado para otimização na existência de muitos objetos com as 
mesmas características intrínsecas (são estáticas e não depende do 
estado do objeto).
• Para reduzir o processamento lento da execução destes muitos objetos 
repetidos, a estruturação faz com que alguns destes dados sejam 
externos em um objeto, simulando assim a existência de mais objetos do 
que o realmente existente; com esta diminuição de objetos podemos 
criar uma execução mais rápida.
Padrões GoF de Estruturais - Flyweight
Estrutura
Padrões GoF de Estruturais - Flyweight
Exemplo
Padrões GoF Comportamentais – Proxy
Objetivo:
“Fornecer um substituto ou marcador da localização de outro objeto para 
controlar o acesso a esse objeto.” 
Vantagem:
• Ao utilizar um substituto, pode-se fazer desde operações otimizadas até 
proteção do acesso ao objeto.
• Transparência, pois é utilizada a mesma sintaxe na comunicação entre o 
cliente e o objeto real;
Padrões GoF Comportamentais – Proxy
Quando utilizar:
• O padrão Proxy é utilizado quando um sistema quer utilizar um objeto 
real, mas por algum motivo ele não está disponível. 
• A solução então é providenciar um substituto que possa se comunicar com 
esse objeto quando ele estiver disponível. 
• O cliente passa a usar o intermediário em vez do objeto real. O 
intermediário possui uma referencia para o objeto real e repassa 
asinformações do cliente, filtrando dados e acrescentando informações.
Padrões GoF Comportamentais – Proxy
Exemplo: controlar o acesso aos objetos verificando se quem chama possui a 
devida permissão.
Padrões GoF Comportamentais
Chain of Responsability: Evita o acoplamento do remetente de uma
solicitação ao seu destinatário, dando a mais de um objeto a chance de
tratar a solicitação. Encadeia os objetos receptores e passa a solicitação ao
longo da cadeia até que um objeto a trate.
Command: Encapsula uma solicitação como um objeto, desta forma
permitindo que você parametrize clientes com diferentes solicitações,
enfileire ou registre (log) solicitações e suporte operações que podem ser
desfeitas.
Interpreter: Dada uma linguagem, define uma representação para sua
gramática juntamente com um interpretador que usa a representação para
interpretar sentenças nesta linguagem.
Iterator: Cria um iterador para interagir com os objetos, retirando a
iteração das responsabilidades do próprio objeto.Padrões GoF Comportamentais
Mediator: Define um objeto que encapsula como um conjunto de objetos
interage. O Mediator promove o acoplamento fraco ao evitar que os objetos
se refiram explicitamente uns aos outros, permitindo que você varie suas
interações independentemente.
Memento: Sem violar a encapsulação, captura e externaliza um estado
interno de um objeto, de modo que o mesmo possa posteriormente ser
restaurado para este estado.
Observer: Define uma dependência um-para-muitos entre objetos, de
modo que, quando um objeto muda de estado, todos os seus dependentes
são automaticamente notificados e atualizados.
Padrões GoF Comportamentais
State: Permite que um objeto altere seu comportamento quando seu estado
interno muda. O objeto parecerá ter mudado de classe.
Strategy: Define uma família de algoritmos, encapsula cada um deles e os
faz intercambiáveis. O Strategy permite que o algoritmo varie
independentemente dos clientes que o utilizam.
Template Method: Define o esqueleto de um algoritmo em uma operação,
postergando a definição de alguns passos para subclasses. O Template
Method permite que as subclasses redefinam certos passos de um algoritmo
sem mudar sua estrutura.
Visitor: Representa uma operação a ser executada sobre os elementos da
estrutura de um objeto. O Visitor permite que você defina uma nova
operação sem mudar as classes dos elementos sobre os quais opera, criando
métodos virtualmente.
Padrões GoF Comportamentais - Strategy
Propósito
• Definir uma família de algoritmos, encapsular cada um, e fazê-los 
intercambiáveis.
• Strategy permite que algoritmos variem independentemente entre clientes 
que os utilizam. 
Aplicabilidade
• Quando muitas classes relacionadas diferem apenas no 
comportamento
• Quando variações de um algoritmo são necessárias e quando esses 
algoritmos puderem ser reutilizados
• Quando um algoritmo utilizar informações que não devem ser 
conhecidas pelo cliente
• Quando uma classe define muitos comportamentos, e esses aparecem 
como múltiplo comandos condicionais
• Diferentes algoritmos são apropriados para diferentes aplicações.
• Tornar o algoritmo parte do cliente dificulta adição de novos 
algoritmos.
Padrões GoF Comportamentais - Strategy
Consequências Positivas
• Uma alternativa à herança. Deixando o código mais limpo, fácil de 
entender e manter.
• Possibilidade de variar algoritmos dinamicamente
• O encapsulamento de algoritmos em classes separadas permite 
variações de algoritmo independente do Contexto.
• Eliminação de comandos condicionais.
Consequências Negativas
• Mais objetos no Projeto
• Clientes devem ter conhecimento dos diferentes tipos de estratégia, 
ou seja, só devemos utilizar Strategy quando a mudança de 
comportamento for relevante para os clientes
Padrões GoF Comportamentais - Strategy
Estrutura
Padrões GoF Comportamentais - Strategy
Participantes:
– Strategy (Compositor)
• Define uma interface comum para todos os algoritmos suportados. Context
usa esta interface para chamar o algoritmo definido por uma ConcreteStrategy.
– ConcreteStrategy
• Implementa o algoritmo usando a interface de Strategy.
– Context (Composition)
• É configurado com um objeto ConcreteStrategy;
• Mantém uma referência para um objeto Strategy;
Padrões GoF Comportamentais - Strategy
Padrões GoF Comportamentais - State
Definição: permite que um objeto altere o seu comportamento 
quando um estado interno muda.
Aplicabilidade: 
• o comportamento de um objeto depende do seu estado e ele 
pode mudar seu comportamento em tempo de execução, 
dependendo desse estado;
• operações que tem comandos condicionais grandes, de várias 
alternativas e que dependem do estado do objeto. 
Frequentemente, várias operações conterão essa mesma 
estrutura condicional.
Padrões GoF Comportamentais - State
Estrutura
Padrões GoF Comportamentais - State
Participantes:
• Context é a interface que será usada pelo clientes, Context
mantém uma instância do objeto que implementa a interface 
State corrente. 
• State é a interface que deverá ser implementada para definir 
comportamentos.
• Concrete State
Subclasse que implementa um comportamento associado ao 
estado de contexto.
Padrões GoF Comportamentais - State
Exemplo: Controle Bancário
Padrões GoF Comportamentais – Chain of Responsability
Propósito: permitir que mais de uma classe tenha a chance de atender a 
uma requisição de serviço. As classes são encadeadas e fracamente 
acopladas, pois o único vínculo que possuem é o link para a chamada das 
outras classes na cadeia 
Padrões GoF Comportamentais – Chain of Responsability
• Quando um cliente emite uma solicitação, esta se propaga ao longo da 
cadeia até que um objeto Handler assuma a responsabilidade de tratá-
la.
Padrões GoF Comportamentais – Chain of Responsability
• Estrutura
Padrões GoF Comportamentais – Chain of Responsability
Participantes:
Handler: 
Define uma interface para tratar solicitações Implementa o link para o 
sucessor 
ConcreteHandler:
Trata as solicitações em que for o responsável. Pode acessar seu 
sucessor, caso a solicitação não seja de sua responsabilidade
Client:
Inicia a solicitação, que vai para algum objeto ConcreteHandler na 
cadeia.
Padrões GoF Comportamentais – Chain of Responsability
Consequências do uso:
1 - Redução de acoplamento: Um objeto não tem que saber que outros 
objetos tratam uma solicitação.
2 - Objetos mantêm referências apenas para o sucessor e não para todos 
os receptores candidatos.
3 - Flexibilidade adicional na atribuição de responsabilidade: É possível 
acrescentar ou mudar responsabilidades em tempo de execução.
4 – A recepção não é garantida: Uma vez que uma solicitação não tem 
receptor explícito, não há total garantia de que ela será tratada. Se uma 
classe não for implementada corretamente também não há garantia de 
tratamento da solicitação.
Padrões GoF Comportamentais – Chain of Responsability
abstract class Approver
{
protected Approver successor;
public void SetSuccessor(Approver successor)
{
this.successor = successor;
}
public abstract void ProcessRequest(Purchase purchase);
}
/// <summary>
/// The 'ConcreteHandler' class
/// </summary>
class Director : Approver
{
public override void ProcessRequest(Purchase purchase)
{
if (purchase.Amount < 10000.0)
{
Console.WriteLine("{0} approved request# {1}",
this.GetType().Name, purchase.Number);
}
else if (successor != null)
{
successor.ProcessRequest(purchase);
}
}
}
class VicePresident : Approver
{
public override void ProcessRequest(Purchase purchase)
{
if (purchase.Amount < 25000.0)
{
Console.WriteLine("{0} approved request# {1}",
this.GetType().Name, purchase.Number);
}
else if (successor != null)
{
successor.ProcessRequest(purchase);
}
}
}
/// <summary>
/// The 'ConcreteHandler' class
/// </summary>
class President : Approver
{
public override void ProcessRequest(Purchase purchase)
{
if (purchase.Amount < 100000.0)
{
Console.WriteLine("{0} approved request# {1}",
this.GetType().Name, purchase.Number);
}
else
{
Console.WriteLine(
"Request# {0} requires an executive meeting!",
purchase.Number);
}
}
Padrões GoF Comportamentais – Chain of Responsability
class Purchase
{
private int _number;
private double _amount;
private string _purpose;
// Constructor
public Purchase(int number, double amount, string 
purpose)
{
this._number = number;
this._amount = amount;
this._purpose = purpose;
}
// Gets or sets purchase number
public int Number
{
get { return _number; }
set { _number = value; }
}
// Gets or sets purchase amount
public double Amount
{
get { return _amount; }
set { _amount = value; }
}
// Gets or sets purchase purpose
public string Purpose
{
get { return _purpose;}
set { _purpose = value; }
}
}
}
Padrões GoF Comportamentais – Chain of Responsability
class MainApp
{
static void Main()
{
// Setup Chain of Responsibility
Approver larry = new Director();
Approver sam = new VicePresident();
Approver tammy = new President();
larry.SetSuccessor(sam);
sam.SetSuccessor(tammy);
// Generate and process purchase requests
Purchase p = new Purchase(2034, 350.00, "Assets");
larry.ProcessRequest(p);
p = new Purchase(2035, 32590.10, "Project X");
larry.ProcessRequest(p);
p = new Purchase(2036, 122100.00, "Project Y");
larry.ProcessRequest(p);
// Wait for user
Console.ReadKey();
}
Padrões GoF Comportamentais – Command
Definição:
"Encapsular uma requisição como um objeto, permitindo que clientes
parametrizem diferentes requisições e suportar operações reversíveis." 
[GoF]
Objetivo:
• Encapsular solicitações em um objeto e utilizar suas ações sem
conhecer sua implementação;
• Possibilitar operações de fazer e desfazer;
Padrões GoF Comportamentais – Command
Objetivo: 
• Encapsular uma solicitação como um objeto, permitindo que clientes sejam 
configurados para tratar diferentes solicitações, log de solicitações e suportar 
capacidade de desfazer operações.
Motivação:
• Algumas vezes é necessário solicitar uma operação sem nenhum
conhecimento de como esta será implementada;
• Podemos simplesmente não conhecer o objeto que vai receber a 
delegação para executar aquela operação;
Solução: 
• encapsular esta tarefa num objeto (um Command) e através dele delegar
esta tarefa para outra classe, que por sua vez sabe como executar a 
operação propriamente dita (o Receiver);
Padrões GoF Comportamentais – Command
Consequência:
• Promove o desacoplamento do objeto que solicita uma operação do 
objeto que vai realizar esta operação propriamente dita;
• Solicitações em alto nível: o objeto não precisa ter nenhum
conhecimento sobre a implementação da operação;
• Commands podem ser manipulados e estendidos com qualquer 
outro objeto.
• É fácil adicionar novos Commands porque não é necessário modificar 
classes existentes.
Padrões GoF Comportamentais – Command
Diagrama de Classe
Padrões GoF Comportamentais – Command
Participantes:
• Command: Interface para execução de uma operação;
• ConcreteCommand: Vincula um objeto Receiver a uma ação e 
implementa os métodos abstratos da classe Command;
• Client: Cria um objeto ConcreteCommand e estabelece o seu Receiver;
• Invoker: Envia solicitações ao Command;
• Receiver: Implementa as ações que serão utilizadas pelo
ConcreteCommand;
Padrões GoF Comportamentais – Command
Exemplo:
Command
Execute()
PasteCommand
buffer
Execute()
Cola o buffer no 
documento.
OpenCommand
Execute()
QuitCommand
Execute()
Abre uma caixa de 
diálogo para 
perguntar ao usuário 
o nome do 
documento e 
adiciona o mesmo à 
aplicação.
Se o documento 
foi modificado 
salve o 
documento. 
Caso contrário 
saia da 
aplicação.
Padrões GoF Comportamentais – Command
• A classe abstrata Command declara uma interface para executar operações. 
Na sua forma mais simples, essa interface possui uma operação abstrata 
Execute( ).
• Subclasses de Command (Concrete Commands) implementam a operação 
Execute( ) de diferentes maneiras para atender aos diversos tipos de 
operações.
Padrões GoF Comportamentais – Command
Exemplo: Portão de garagem
Padrões GoF Comportamentais – Observer
Propósito:
• Permitir que um objeto sujeito mantenha uma lista com seus dependentes, 
chamados de observadores, e possa notificá-los automaticamente de 
eventuais mudanças de estado, geralmente chamando um de seus métodos.
• Também conhecido como: Dependents, Publish-Subscribe, Event-Generator
Aplicabilidade
• Quando o objeto sujeito não sabe exatamente quantos objetos de 
observação tem. 
• Quando o objeto sujeito deve ser capaz de informar seus objetos 
observadores sem saber quem são esses objetos.
Padrões GoF Comportamentais – Observer
Consequências Positivas
• O Subject faz broadcast da notificação. Os Observers têm total liberdade para 
fazer o que quiserem, inclusive nada.
• Fraco Acoplamento.
Consequência Negativas
• O custo de uma mudança ao estado de um Subject pode ser grande se 
houver muitos Listeners. 
Padrões GoF Comportamentais – Observer
Diagrama:
Padrões GoF Comportamentais – Observer
• Subject : Conhece seus Observers. Qualquer número de objetos pode 
observar um Subject Provê uma interface para adicionar e remover 
Observers.
• Observer: Define uma interface para objetos que recebem avisos de 
mudança de estado de um Subject.
• ConcreteObserver : implementa a interface Observer para manter seu 
estado consistente com o Subject.
Padrões GoF Comportamentais – Observer
Exemplo: estação meteorológica
Padrões GoF Comportamentais – Template Method
Objetivo
• Define o esqueleto de um algoritmo em uma operação, deixando 
alguns passos para serem implementados por subclasses. 
• O Template Method deixa subclasses redefinirem certos passos de um 
algoritmo sem alterar a estrutura do algoritmo
Aplicabilidade
• Para implementar as partes invariantes de um algoritmo uma única vez 
e deixar que as subclasses implementem o comportamento que pode 
variar.
• Quando comportamento comum entre subclasses deve ser fatorado e 
locado em uma classe comum para evitar duplicação de código.
Padrões GoF Comportamentais – Template Method
Conseqüências
• Template Methods constituem uma técnica fundamental para a 
reutilização de código. São particularmente importantes para Biblioteca 
de Classes, pois representam um mecanismo para fatorar 
comportamento comum.
• Templates Methods levam a uma inversão de controle. Também 
chamado de “Hollywood principle”,
“Don´t call us, we´ll call you”
Padrões GoF Comportamentais – Template Method
Estrutura
Participantes
ClasseAbstrata : Define operações primitivas abstratas que as subclasses concretas definem para 
implementar passos de um algoritmo
ClasseConcreta : Implementa as operações abstratas para desempenhar as etapas do algoritmo 
que tenham comportamento específico a esta classe
Padrões GoF Comportamentais – Template Method
Exemplo: Financiamento imobiliário
Padrões GoF Comportamentais – Visitor
Objetivo
• Aumentar a coesão das classes isolando em outras classes tarefas 
pouco coesas
• Visitor permite definir uma nova operação sem alterar as classes dos 
elementos nos quais a operação atua 
Implementação
• Faça com que cada elemento aceite um objeto "visitante" e o chame 
através de um método apropriado 
Padrões GoF Comportamentais – Visitor
• Quando usar o padrão Visitor?
• Uma estrutura de objetos contém muitas classes de objetos com 
interfaces diferentes e se deseja realizar operações nestes objetos 
que dependem das classes concretas 
• Muitas operações distintas e não relacionadas devem ser realizadas 
numa estrutura de objetos e deseja-se evitar "poluir" as classes com 
estas operações. Visitor permite que se agrupe as operações 
relacionadas numa mesma classe 
Padrões GoF Comportamentais – Visitor
Estrutura
Padrões GoF Comportamentais – Visitor
Exemplo 1:
Em uma ferramenta Case deve ser possível gerar as informações de 
casos de uso e classes em HTML, PDF, RTF, TeX, etc. Entretanto, não é 
desejável que a classe que representa um caso de uso tenha métodos 
para cada tipo de geração.
Exemplo 2:
Padrões GoF Comportamentais – Memento
Objetivo:
• Permitir que um objeto volte ao seu estado anterior em operações 
de "undo" ou "redo".
Implementação:
• O cliente solicita um Memento do objeto de origem quando ele 
precisa de ponto de verificação do estado doobjeto de origem.
• O objeto de origem inicializa o Memento com uma caracterização de 
seu estado.
Padrões GoF Comportamentais – Memento
Estrutura
Originator – O objeto que conhece como se salvar 
Caretaker – O objeto que conhece quando the Originator precisa se salvar e 
restaurar. 
Memento – guarda o estado que é escrito e lido pelo Originator.
Padrões GoF Comportamentais – Memento
Exemplo:
Padrões GoF Comportamentais – Interator
• Objetivo
• Prover uma forma de sequencialmente acessar os elementos de 
uma coleção sem expor sua representação interna. Também 
conhecido como Cursor. 
• Motivação
• Queremos isolar o uso de uma estrutura de dados de sua 
representação interna de forma a poder mudar a estrutura sem 
afetar quem a usa.
• Para determinadas estruturas, pode haver formas diferentes de 
caminhamento e queremos encapsular a forma exata de 
caminhamento 
Padrões GoF Comportamentais – Interator
• A idéia do iterador é de retirar da coleção a responsabilidade de 
acessar e caminhar na estrutura e colocar a responsabilidade num 
novo objeto separado chamado um iterador
• A interface Iterador: Define uma interface para acessar os 
elementos da coleção 
• A classe Iterador: Implementa a interface Iterador
Padrões GoF Comportamentais – Interator
Aplicabilidade
• Para acessar o conteúdo de uma coleção sem expor suas 
representação interna 
• Para suportar múltiplas formas de caminhamento 
• Para prover uma interface única para varrer coleções diferentes 
Padrões GoF Comportamentais – Interator
Estrutura
Padrões GoF Comportamentais – Interator
• Exemplo:
Padrões GoF Comportamentais – Mediator
Objetivo:
Definir um objeto que encapsula a forma como um conjunto de objetos 
interage. O Mediator promove o acoplamento fraco ao evitar que os objetos 
se refiram uns aos outros explicitamente e permitir variar suas interações 
independentemente.
Problema
• Como permitir que um grupo de objetos se comunique entre si sem que 
haja acoplamento entre eles ?
• Como remover o forte acoplamento presente em relacionamentos muitos 
para muitos ?
Padrões GoF Comportamentais – Mediator
Solução
• Introduzir um mediator : Objetos podem se comunicar sem se conhecer.
• Um objeto Mediador deve encapsular toda a comunicação entre um 
grupo de objetos
• Cada objeto participante conhece o mediador mas ignora a existência dos 
outros objetos; 
• O mediador conhece cada um dos objetos participantes; 
• A interface do Mediador é usada para iniciar a comunicação e receber 
notificações
• O mediador recebe requisições dos remetentes; 
• O mediador repassa as requisições aos destinatários; 
Padrões GoF Comportamentais – Mediator
Estrutura
Padrões GoF Comportamentais – Mediator
Participantes (Classes)
• Mediator - Define uma interface para comunicação com os objetos 
Colleague; 
• ConcreteMediator - Conhece as classes Colleague e implementa a 
comunicação e transferência de mensagens entre as classes Colleague; 
• Classes Colleague - Mantém uma referência ao seu objeto Mediator .
Se comunicam com o Mediator sempre que necessário; 
Padrões GoF Comportamentais – Mediator
Participantes (Classes)
• Mediator - Define uma interface para comunicação com os objetos 
Colleague; 
• ConcreteMediator - Conhece as classes Colleague e implementa a 
comunicação e transferência de mensagens entre as classes Colleague; 
• Classes Colleague - Mantém uma referência ao seu objeto Mediator .
Se comunicam com o Mediator sempre que necessário; 
Padrões GoF Comportamentais – Mediator
Vantagens
• Desacoplamento entre os diversos participantes da rede de comunicação: 
participantes não se conhecem; 
• Eliminação de relacionamentos muitos para muitos (são todos substituídos 
por relacionamentos um para muitos); 
• A política de comunicações está centralizada no mediador e pode ser 
alterada sem mexer nos colaboradores; 
Desvantagens
• A centralização pode ser uma fonte de gargalos de desempenho e de risco 
para o sistema em caso de falha; 
• Na prática os mediadores tendem a se tornarem mais complexos; 
Padrões GoF Comportamentais – Mediator
Exemplo:
• um aplicativo que trocasse mensagem entre diversas plataformas móveis, 
um Android enviando mensagem para um iOS, um Symbian trocando 
mensagens com um Android. O problema é que cada uma destas 
plataforma implementa maneiras diferentes de receber mensagens e não 
seria uma boa solução criar vários métodos para cada uma das 
plataformas. 
Padrões GoF Comportamentais – Interpreter
Objetivo: 
“O padrão Interpreter recebe uma linguagem e define uma representação 
para sua gramática junto com um interpretador que usa a representação para 
interpretar sentenças na linguagem”. (ROCHA, 2003).
Padrões GoF Comportamentais – Interpreter
Estrutura:
Padrões GoF Comportamentais – Interpreter
Exemplo:
converter uma String ,representando um número romano, em um inteiro que 
represente seu valor decimal.
Padrões GoF Comportamentais – Interpreter
Exemplo:
converter uma String ,representando um número romano, em um inteiro que 
represente seu valor decimal.