padroes de projeto - introducao
TRANSCRIPT
Padrões de ProjetoIntrodução
Prof. Eduardo Bezerra
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)
2
ALEXANDER, C. et al. A Pattern Language: Towns, Buildings, Construction. Oxford University Press, New York, NY, 1977.
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
5Fonte: http://java.sun.com/blueprints/corej2eepatterns/Patterns/
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 etal, 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
Fonte da figura: GoF Book9
Catálogo GoF
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
2. Builder
3. Factory Method
4. Prototype
5. Singleton
6. Adapter
7. Bridge
8. Composite
9. Decorator
10. Facade
11. Flyweight
12. Proxy
13. Chain of Responsibility
14. Command
15. Interpreter
16. Iterator
17. Mediator
18. Memento
19. Observer
20. State
21. Strategy
22. Template Method
23. Visitor
Padrões de CriaçãoPadrões EstruturaisPadrões de Comportamento
14
Fonte da figura: Argo Navis, curso J930 - Padrões de Design
Categorização dos padrões GoF
15
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ãotiveram sucesso (gambiarras).
– Podem também incluir soluções re-trabalhadas que sejam efetivas.
– Veja http://www.antipatterns.com/
35