Aula Padroes

PADRÕES DE PROJETO DE SOFTWARE
Fundamentos de Padrão de Projeto

O que veremos nesta primeira aula
 Conhecer o conceito de padrão de projeto

e a suas aplicações;
 Entender a descrição de um padrão de
projeto e como usar;
 Conhecer as duas principais famílias de
padrões de projeto que serão estudadas
no decorrer da disciplina;
 Iniciar o estudo dos padrões de projeto da
família GoF.
FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

Introdução
• Projetar software OO reusável e de boa qualidade é uma tarefa

difícil;
• Para realizar essa tarefa a contento, projetistas experientes usam
soluções de sucesso com as quais já trabalharam no passado;
• Isso leva à descoberta de padrões de projeto;
• Durante duas décadas, a comunidade de padrões vem se desenvolvendo
de acordo com essa dinâmica.

O que é um padrão?
• Maneira testada ou documentada de alcançar um objetivo qualquer;
• Padrões são comuns em várias áreas da engenharia;
• Design Patterns, ou Padrões de Projeto;

• Padrões para alcançar objetivos na engenharia de software usando
classes e métodos em linguagens orientadas a objeto;
• Inspirado em "A Pattern Language" de Christopher Alexander, sobre
padrões de arquitetura de cidades, casas e prédios;
• "Design Patterns" de Erich Gamma, John Vlissides, Ralph Jonhson e
Richard Helm, conhecidos como "The Gang of Four", ou GoF,
descreve 23 padrões de projeto úteis
"Cada padrão descreve um problema que ocorre repetidas vezes em nosso

ambiente, e então descreve o núcleo da solução para aquele problema, de
tal maneira que pode-se usar essa solução milhões de vezes sem nunca
fazê-la da mesma forma duas vezes"
Christopher Alexander, sobre padrões em Arquitetura

"Os padrões de projeto são descrições de objetos que se comunicam e

classes que são customizadas para resolver um problema genérico de
design em um contexto específico"
Gamma, Helm, Vlissides & Johnson, sobre padrões em software

“Um padrão é a abstração de uma forma concreta que ocorre muitas vezes
em contextos específicos.”
Riehle & Zullighoven, 1996

“Resolve um problema. É um conceito provado. A solução não é óbvia.

Descreve um relacionamento.”
Jim Coplien, 1996

Padrões - características
• Capturam soluções de projeto exaustivamente refinadas com o passar

do tempo;
• São o resultado de um longo processo de projeto, re-projeto, teste e
reflexão sobre o que torna um sistema mais flexível, reusável e modular;

Catálogos de padrões
Um catálogo de padrões é um grupo de padrões que estão relacionados
de uma certa forma e podem ser usados juntos ou independentemente:
• Core JEE(Java Enterprise Edition);

• PoEAA(PatternsofEnterprise Application Architecture);
• POSA(Pattern-OrientedSoftware Architecture)
• GRASP(General Responsibility Assignment Software
Patterns/Principles)
• GoF(Gang ofFour)

Catálogo - GoF

Por que aprender padrões?

Aprender com a experiência dos outros
• Identificar problemas comuns em engenharia de software e utilizar soluções
testadas e bem documentadas;
• Utilizar soluções que têm um nome: facilita a comunicação, compreensão e
documentação;
Aprender a programar bem com orientação a objetos
• Os 23 padrões de projeto "clássicos" utilizam as melhores práticas em OO
para atingir os resultados desejados;
Desenvolver software de melhor qualidade
• Os padrões utilizam eficientemente polimorfismo, herança, modularidade,
composição, abstração para construir código reutilizável, eficiente, de alta
coesão e baixo acoplamento;
Elementos de um padrão
• Nome
• Problema:
• Quando aplicar o padrão, em que condições?
• Solução:
• Descrição abstrata de um problema e como usar os elementos
disponíveis (classes e objetos) para solucioná-lo
• Consequências:
• Custos e benefícios de se aplicar o padrão
• Impacto na flexibilidade, extensibilidade, portabilidade e
eficiência do sistema
Formas de classificação
Gamma et al [1] os classifica de duas formas
• Por propósito:
• criação de classes e objetos,
• alteração da estrutura de um programa,
• controle do seu comportamento
• Por escopo: classe ou objeto
Metsker [2] os classifica em 5 grupos, por intenção (problema a ser solucionado):
• oferecer uma interface,
• atribuir uma responsabilidade,
• realizar a construção de classes ou objetos
• controlar formas de operação
• implementar uma extensão para a aplicação
Categorização por escopo
• Escopo de classe
• Descrevem relacionamentos entre classes e suas subclasses
(herança).
• Estáticos: relacionamentos são fixos e definidos em tempo de
compilação.
• Escopo de objeto
• Descrevem relacionamentos entre objetos.
• Dinâmicos: relacionamentos entre objetos podem ser alterados
em tempo de execução.

Categorização por finalidade
• Estruturais
• Tratam da composição de classes e objetos para formar
estruturas complexas.
• Associados à maneira como classes e objetos são organizados
estruturalmente.
• Oferecem formas efetivas para usar conceitos OO como herança
e composição.
• São abstrações de aspectos estruturais

Categorização por finalidade
De criação
• Associados ao processo de criação de objetos
• Tornam um sistema independente de como seus objetos são
criados, compostos e representados
Comportamentais
• Têm a ver com a maneira pela qual responsabilidades são
distribuídas a classes e objetos durante a realização de uma
tarefa.
• São abstrações de aspectos comportamentais
Classificação dos 23 padrões segundo GoF*

Resumo do padrões GoF
1. Adapter: Converter a interface de uma classe em outra interface

esperada pelos clientes.
2. Façade: Oferecer uma interface única de nível mais elevado para
um conjunto de interfaces de um subsistema.
3. Composite: Permitir o tratamento de objetos individuais e
composições hierárquicas desses objetos de maneira uniforme.
4. Bridge: Desacoplar uma abstração de sua implementação, de tal
forma que os dois possam variar independentemente.
5. Singleton: Garantir que uma classe só tenha uma única instância, e
prover um ponto de acesso global a ela.
6. Observer: Definir uma dependência um-para-muitos entre objetos

para que, quando um objeto mudar de estado, os seus dependentes
sejam notificados e atualizados.
7. Mediator: Definir um objeto que encapsula a forma como um
conjunto de objetos interage.
8. Proxy: Prover um substituto ou ponto através do qual um objeto
possa controlar o acesso a outro.
9. Chain of Responsibility: Compor objetos em cascata para, através
dela, delegar uma requisição até que um objeto a sirva.

10. Flyweight: Usar compartilhamento para suportar eficientemente

grandes quantidades de objetos complexos.
11. Builder: Separar a construção de objeto complexo da representação
para criar representações diferentes com mesmo processo.
12. FactoryMethod: Definir uma interface para criar um objeto mas
deixar que subclasses decidam que classe instanciar.
13. Abstract Factory: Prover interface para criar famílias de objetos
relacionados ou dependentes sem especificar suas classes
concretas.

14. Prototype: Especificar tipos a criar usando uma instância como

protótipo e criar novos objetos ao copiar este protótipo.
15. Memento: Externalizar o estado interno de um objeto para que o
objeto possa ter esse estado restaurado posteriormente.
16. TemplateMethod: Definir o esqueleto de um algoritmo dentro de
uma operação, deixando alguns passos a serem preenchidos pelas
subclasses.
17. State: Permitir a um objeto alterar o seu comportamento quando o
seu estado interno mudar.


18. Strategy: Definir uma família de algoritmos, encapsular cada um, e fazê-
los intercambiáveis.
19. Command: Encapsular uma requisição como objeto, para parametrizar
clientes com diferentes requisições, filas e dar suporte a ações reversíveis.
20. Interpreter: Dada uma linguagem, definir uma representação para sua
gramática junto com um interpretador.
21. Decorator: Anexar responsabilidades adicionais a um objeto
dinamicamente
22. Iterator: Prover acesso sequencial a elementos de um objeto agregado,
sem expor sua representação interna
23. Visitor: Representar uma operação a ser realizada sobre os elementos de
uma estrutura de objetos
Classificação dos padrões GoF segundo Metsker [2]

Padrões de construção
A maneira padrão de construir objetos em Java é através de construtores
1. Toda classe tem um construtor: operação declarada com o mesmo
nome da classe, que não retorna valor e só pode ser usada na
inicialização
2. O construtor é uma tarefa de classe (estática)
3. Se um construtor não é explicitamente declarado em uma classe, o
sistema cria um construtor default para a classe
4. Todo construtor inicializa a hierarquia de classes do objeto antes de
executar
5. Todo construtor sempre contém ou uma referência à superclasse
(implícita ou explícita) ou uma referência a outro construtor da classe
como primeira ou única instrução
Construtores em Java

Além dos construtores

1. Construtores em Java definem maneiras padrão de construir objetos. Sobrecarga
permite ampla flexibilidade
2. Alguns problemas em depender de construtores
• Cliente pode não ter todos os dados necessários para instanciar um objeto
• Cliente fica acoplado a uma implementação concreta (precisa saber a classe
concreta para usar new com o construtor)
• Cliente de herança pode criar construtor que chama métodos que dependem
de valores ainda não inicializados (vide processo de construção)
• Objeto complexo pode necessitar da criação de objetos menores
previamente, com certo controle difícil de implementar com construtores
• Não há como limitar o número de instâncias criadas.

Além dos construtores

3. Padrões que oferecem alternativas à construção de objetos
• Factory Method: adia a decisão sobre qual classe concreta instanciar
• Abstract Factory: construir uma família de objetos que compartilham um
"tema" em comum
• Builder: obtém informação necessária em passos antes de requisitar a
construção de um objeto
• Prototype: especificar a criação de um objeto a partir de um exemplo
fornecido
• Memento: reconstruir um objeto a partir de uma versão que contém apenas
seu estado interno

Factory method
"Definir uma interface para criar um objeto mas deixar que subclasses
decidam que classe instanciar. Factory Method permite que uma classe
delegue a responsabilidade de instanciamento às subclasses."
[GoF]


Como implementar?
• É possível criar um objeto sem ter conhecimento algum de sua

classe concreta?
 Esse conhecimento deve estar em alguma parte do sistema, mas
não precisa estar no cliente
 FactoryMethod define uma interface comum para criar objetos
 O objeto específico é determinado nas diferentes
implementações dessa interface
 O cliente do FactoryMethod precisa saber sobre
implementações concretas do objeto criador do produto
desejado


Como selecionar o criador?
• Para criar objetos não é mais preciso saber a classe concreta do

objeto a ser criado, mas ainda é preciso saber a classe do criador.
• Para escolher qual criador usar sem que seja preciso instanciá-lo
com um construtor, crie uma classe Factory com um método
estático que decida qual criador usar com base em um parâmetro

Prós e contras
• Vantagens
• Criação de objetos é desacoplada do conhecimento do tipo concreto do
objeto
• Conecta hierarquias de classe paralelas
• Facilita a extensibilidade
• Desvantagens
• Ainda é preciso saber a classe concreta do criador de instâncias (pode-
se usar uma classe Factory, com método estático e parametrizado que
chame diretamente o Factory Method):

Exemplo 1
public class Montadora{
public void novoCarro(String tipo){
Carro carroZero;
if(tipo.equals(“Vectra”))
carroZero = new Vectra();
else
if(tipo.equals(“Omega”))
carroZero = new Omega();
else
if(tipo.equals(“Gol”))
carroZero = new Gol();
else
if(tipo.equals(“Golf”))
carroZero = new Golf();
}
};
Continuação do Exemplo 1

Exemplo 2

public abstract class Aplicacao {
private Documento doc;
abstract Documento criaDocumento(); //Abstração do Factory Method
void novoDocumento() {
this.doc = this.criaDocumento();
}
void abrirDocumento() {
this.doc.abrir();
}
}
public abstract class Documento {
void abrir() {
System.out.println("Documento:Abrir documento!");
}
void fechar() {
System.out.println("Documento:Fechar documento!");
}
void gravar() {
System.out.println("Documento:Gravar documento!");
}
}
public class MinhaAplicacao extends Aplicacao {
/**
* Uma implementação do Factory Method. Este método é
* especializado na criação de documentos do tipo MeuDocumento
*/
Documento criaDocumento() {
return new MeuDocumento();
}
}
public class MeuDocumento extends Documento {

}

Abstract Factory
"Prover uma interface para criar famílias de objetos relacionados ou

dependentes sem especificar suas classes concretas."
[GoF]

Problema

Estrutura de Abstract Factory

Exemplo 1

Exemplo 2

public abstract class WidgetFactory {
public static WidgetFactory obterFactory() {
if(Configuracao.obterInterfaceGraficaAtual()==Configuracao.MotifWidget)
return new MotifWidgetFactory();
else
return new QtWidgetFactory();
}
public abstract Botao criarBotao();
}

public class MotifWidgetFactory extends WidgetFactory{
public Botao criarBotao() {
return new BotaoMotif();
}
}
public class QtWidgetFactory extends WidgetFactory {

public Botao criarBotao() {
return new BotaoQt();
}
}

public abstract class Botao {
public abstract void desenhar();
}
public class BotaoMotif extends Botao {
public void desenhar() {
System.out.println("Eu sou um botao Motif!");
}
}
public class BotaoQt extends Botao {
public void desenhar() {
System.out.println("Eu sou um botao Qt!");
}
}
public class Cliente
{
public static void main(String[] args)
{
WidgetFactory factory = WidgetFactory.obterFactory();
Botao botao = factory.criarBotao();

botao.desenhar();
}
}

Bibliografia
Utilizando UML e Padrões: uma introdução à análise e ao
projeto orientados a objetos - 3ª Edição
Autor: Larman, Craig
Padrões de Projeto: soluções reutilizáveis de software

orientado a objetos
Autor: Gamma, Erich ... [et al]

Fonte das imagens
Slide 4:
http://en.wikipedia.org/wiki/File:2_duplo_lego_bricks.jpg
http://lucasmauess.blogspot.com/2011/07/coisas-incriveis-feitas-em-lego.html
Slide 6:
http://www.devmedia.com.br/articles/viewcomp.asp?comp=10635
Slide 7:
http://www.anossaescola.com/cr/testes/RMarques/professor.gif
http://sitededicas.ne10.uol.com.br/curgraca3.htm
Slide 8:
http://pedrocosta.wordpress.com/
http://despguerino.com/pictures.html
Slide 9:
http://www.dsc.ufcg.edu.br/~jacques/cursos/p2/html/oo/usando.htm
Slide 10:
http://carrosbr.com/vw-fox-e-cross-fox-2012.htm
http://www.carrosecorridas.com.br/2010/03/volkswagen-fox-e-crossfox-sao-os-modelos-preferidos-do-publico-feminino/
Slide 13:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
Slide 14:
http://www.alexandresmcampos.adm.br/fiec/jcid/java.htm
http://viralpatel.net/blogs/2008/12/java-virtual-machine-an-inside-story.html

Aula Padroes

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aula Padroes

Enviado por

Direitos autorais:

Formatos disponíveis

PADRÕES DE PROJETO DE SOFTWARE

Fundamentos de Padrão de Projeto

O que veremos nesta primeira aula

 Conhecer o conceito de padrão de projeto

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

• Projetar software OO reusável e de boa qualidade é uma tarefa

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

• Design Patterns, ou Padrões de Projeto;

"Cada padrão descreve um problema que ocorre repetidas vezes em nosso

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

"Os padrões de projeto são descrições de objetos que se comunicam e

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

“Resolve um problema. É um conceito provado. A solução não é óbvia.

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

• Capturam soluções de projeto exaustivamente refinadas com o passar

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

• Core JEE(Java Enterprise Edition);

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

Por que aprender padrões?

Categorização por escopo

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

Categorização por finalidade

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

Categorização por finalidade

Classificação dos 23 padrões segundo GoF*

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

Resumo do padrões GoF

1. Adapter: Converter a interface de uma classe em outra interface

Resumo do padrões GoF

6. Observer: Definir uma dependência um-para-muitos entre objetos

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

Resumo do padrões GoF

10. Flyweight: Usar compartilhamento para suportar eficientemente

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

Resumo do padrões GoF

14. Prototype: Especificar tipos a criar usando uma instância como

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

Resumo do padrões GoF

Classificação dos padrões GoF segundo Metsker [2]

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

Além dos construtores

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

Além dos construtores

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

• É possível criar um objeto sem ter conhecimento algum de sua

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

Como selecionar o criador?

• Para criar objetos não é mais preciso saber a classe concreta do

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

abstract Documento criaDocumento(); //Abstração do Factory Method

public class MeuDocumento extends Documento {

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1

"Prover uma interface para criar famílias de objetos relacionados ou

FUNDAMENTOS DE PADRÕES DE PROJETO – AULA1