Você está na página 1de 35

Padrões de Projeto

Introdução
Prof. Eduardo Bezerra
edubezerra@gmail.com
Definição
• “Um padrão é uma entidade que descreve um
problema que ocorre freqüentemente, e então
descreve a essência de uma solução para o
problema, de maneira que você possa usar esta
solução um milhão de vezes, sem fazê-la do mesmo
jeito duas vezes.”
Christopher Alexander (Arquiteto e Urbanista)

ALEXANDER, C. et al. A Pattern Language: Towns, Buildings, Construction.


Oxford University Press, New York, NY, 1977. 2
Tipos de padrões de software
• Padrões organizacionais (organizational patterns)
• Padrões de requisitos
• Padrões de análise (analysis patterns)
• Padrões de projeto (design patterns)
• Padrões arquitetônicos (architectural patterns)
• Padrões de implementação (idioms, coding patterns)
• Padrões de testes
• Anti-padrões (anti patterns)

3
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 (Patterns of Enterprise Application Architecture)
– POSA (Pattern-Oriented Software Architecture)
– GRASP (General Responsibility Assignment Software
Patterns/Principles)
– GoF (Gang of Four)

4
Catálogo Core JEE

5
Fonte: http://java.sun.com/blueprints/corej2eepatterns/Patterns/
Catálogo PoEAA

6
Fonte: http://martinfowler.com/eaaCatalog/
Catálogo POSA
• Pattern-Oriented Software Architecture:
– A System of Patterns, F. Buschmann et al, Wiley & Sons,
Chichester, UK, 1996.
– Patterns for Concurrent and Networked Objects, Douglas
C. Schmidt et al, Wiley & Sons, 2000.
– Volume 3: Patterns for Resource Management, Michael
Kircher, Prashant Jain, Wiley & Sons, 2004.
– A Pattern Language for Distributed Computing, Frank
Buschmann et al, Wiley & Sons, 2007.
– On Patterns and Pattern Languages, Frank Buschmann et
al, Wiley & Sons, 2007.
7
Catálogo GRASP
• Low Coupling/High Cohesion
• Expert
• Creator
• Polymorphism
• Pure Fabrication
• Don’t Talk to Strangers (Law of Demeter)
• Controller
• Indirection
• Protected Variations

8
Catálogo GoF

9
Fonte da figura: GoF Book
Categorização dos padrões GoF
• Os 23 padrões GoF podem ser categorizados de
acordo com diversos critérios.
– Dois possíveis critérios são o escopo e a finalidade.
• De acordo com o escopo:
– classe (4)
– objeto (20)
• De acordo com a finalidade:
– estruturais (7)
– de criação (5)
– comportamentais (11)
10
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.
11
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

12
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
13
Categorização por finalidade
1. Abstract Factory 13. Chain of Responsibility
2. Builder 14. Command
3. Factory Method 15. Interpreter
4. Prototype 16. Iterator
5. Singleton 17. Mediator
6. Adapter 18. Memento
7. Bridge 19. Observer
8. Composite 20. State
9. Decorator 21. Strategy
10. Facade 22. Template Method
11. Flyweight 23. Visitor
12. Proxy
Padrões de Criação
Padrões Estruturais
Padrões de Comportamento
14
Categorização dos padrões GoF

15
Fonte da figura: Argo Navis, curso J930 - Padrões de Design
Resumo do padrões GoF (1/7)
• 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. 16
Resumo do padrões GoF (2/7)
• 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.

17
Resumo do padrões GoF (3/7)
• 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.

18
Resumo do padrões GoF (4/7)
• 11. Builder: Separar a construção de objeto
complexo da representação para criar
representações diferentes com mesmo processo.
• 12. Factory Method: 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.

19
Resumo do padrões GoF (5/7)
• 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. Template Method: 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.20
Resumo do padrões GoF (6/7)
• 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
Resumo do padrões GoF (7/7)
• 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.

22
Referências

23
Referências (cont.)
• Gamma et al., Padrões de Projeto - Soluções
Reutilizáveis de Software Orientado a Objetos, Porto
Alegre: Bookman, 2000.
• Freeman et al., Use a Cabeça!: Padrões de Projetos
(Design Patterns), Rio de Janeiro: Alta Books, 2005.
• Steven John Metsker, Design Patterns Java
Workbook. Addison-Wesley, 2002.
• Brown et al., Anti-Patterns: Refactoring Software,
Architectures and Projects in Crisis, Wiley, 1998.

24
Referências (cont.)
• Martin Fowler, Padrões de Arquitetura de Aplicações
Corporativas, Porto Alegre: Bookman, 2006.
• Deepak Alur, John Crupi & Dan Malks, CORE J2EE
Patterns – Melhores Práticas e Estratégias de
Design, 2ª edição, Rio de Janeiro: Campus/Elsevier,
2004.
• Craig Larman, Utilizando UML e Padrões, 3ª edição,
2005, ISBN: 85-363-0358-1, Porto Alegre: Bookman.

25
Material complementar

26
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.
27
Padrões – Outras definições
• “Um padrão é a abstração de uma forma
concreta que ocorre muitas vezes em contextos
específicos.” Riehle & Zullighoven, 1996
• “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 et al., 1994
• “Resolve um problema. É um conceito provado. A
solução não é óbvia. Descreve um
relacionamento.” Jim Coplien, 1996.

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

29
Elementos da descrição GoF (1/3)
• Nome
– nome do padrão
• Intenção
– O que o padrão de projeto faz
• Também conhecimento como
– Outros nomes pelos quais o padrão é conhecido
• Motivação
– Outros nomes pelos quais o padrão é conhecido
• Aplicabilidade
– Descreve situações em que o padrão é aplicável.

30
Elementos da descrição GoF (2/3)
• Estrutura
– Ilustração gráfica dos elementos (classes, interfaces) que constituem o
design do padrão.
• Participantes
– Descrição das responsabilidades de cada elemento do padrão.
• Colaborações
– Descrição das responsabilidades de cada elemento do padrão.
• Conseqüências
– Resultados e compromissos decorrentes da aplicação do padrão.
– Impactos sobre a flexibilidade, estensibilidade, portabilidade ou
desempenho do sistema.

31
Elementos da descrição GoF (2/3)
• Implementação
– Sugestões e dicas para implementar o padrão.
• Exemplo de código
– Exemplos de código em uma linguagem de programação OO.
• Usos conhecidos
– Usos conhecidos do padrão em sistemas reais.
• Padrões relacionados
– Relacionamentos e diferenças com outros padrões.

32
Mecanismos de reúso
• Abstração
• Encapsulamento
• Polimorfismo
• Herança
• Composição e delegação
• Modularização
• Separação de interesses (separation of concerns)
• Desacoplamento e coesão
• Separação entre interface e implementação
• Dividir para conquistar

33
Tipos de padrões de software (1/2)
• Padrões arquitetônicos (architectural patterns)
– Descrevem a estrutura e o relacionamento dos
componentes (subsistemas) de um sistema de
software.
• Padrões de análise (analysis patterns)
– Descrevem grupos de conceitos que representam
construções comuns na modelagem do domínio.
Estes padrões podem ser aplicáveis em um
domínio ou em muitos

34
Tipos de padrões de software (2/2)
• Anti-Padrões (anti patterns)
– Documentam soluções recorrentes que não
tiveram sucesso (gambiarras).
– Podem também incluir soluções re-trabalhadas
que sejam efetivas.
– Veja http://www.antipatterns.com/

35