Nesta apresentação é exibido os principais padrões de projetos para criação de um software baseado em programação orientada a objetos escalável e de forma evolutiva.
Encontrando equilíbrio do DDD enquanto sua aplicação cresce
Design Patterns
1.
2. Palestrantes
• Amanda Moraes
Engenheira da Computação – FACENS
Mestranda em Tecnologia da Informação – UNICAMP (andamento)
Especialista Gestão de Projetos e Inovação – FACENS (andamento)
• Leonardo Lucas Lana
Analista e desenvolvedor de Sistemas – FATEC
Especialista em Engenharia de Software – UNICAMP (andamento)
3. ▸O que é padrão?
Design Patterns – Pattern
Design Patterns – Pattern
4. ▸Qual a diferença de um padrão arquitetural e um padrão de projeto
Padrões arquiteturais conhecidos:
MVC
MVP
MVVM
Orion
Table
Microservices
Design Patterns – Padrões arquiteturais
6. ▸Ideia originada de Christopher Wolfgang
Alexander (Austria)
▸Arquiteto
▸Foi aplicado inicialmente para a arquitetura para
edifícios e cidades e não para programação de
computadores.
Design Patterns
7. ▸"Cada padrão descreve um problema que ocorre uma e outra vez em nosso
ambiente e, em seguida, descreve o núcleo da solução para esse problema,
de tal forma que você pode usar essa solução um milhão de vezes, sem
nunca fazê-lo da mesma maneira duas vezes"
-Christopher Alexander (Architect)
“A Pattern Language”,New York,
Oxford University Press, 197
Design Patterns
8. ▸Mesmo que ele estivesse falando sobre padrões em prédios e cidades, o
que ele diz é verdade sobre padrões de design orientados a objetos.
▸As soluções são expressas em termos de objetos e interfaces em vez de
paredes e portas.
▸No núcleo, ambos os padrões são uma solução para um problema em um
contexto.
▸Simplesmente, os padrões de design ajudam um designer a obter um
design mais rápido
Design Patterns
9. ▸Descreve um padrão de projeto como uma regra de três partes
▸1.) Descrição de um contexto
▸2.) Um problema
▸3.) Uma solução
▸Isso é modificado para padrões de design de software que consiste em
quatro partes
Design Patterns
10. ▸Nome do padrão
▸Um identificador para descrever o problema de design, mas o mais importante é
fornecer um vocabulário comum para que os projetistas de software usem.
▸Problema
▸Uma descrição do problema que o padrão de design pretende resolver.
Design Patterns – 4 Partes essenciais
11. ▸Solução
▸Descreve quais elementos são necessários para compor o design, seus
relacionamentos e seu contexto.
▸Consequências
▸Quais são os resultados e compensações aplicando o padrão de projeto. Permite a
comparação entre diferentes padrões de projeto, para ver se há um melhor ajuste
para o problema real.
Design Patterns – 4 Partes essenciais
12. ▸Dirigido a linguagens que têm suporte de nível de linguagem para
programação orientada a objetos
▸Não exclusivamente, mas seria mais fácil de aplicar com OOP!
▸Diferentes linguagens OOP têm mecanismos diferentes para aplicar
padrões.
Design Patterns – Programming Languages
13. ▸GOF – Gang of Four
▸Erich Gamma
▸John Vlissides
▸Ralph Johnson
▸Richard Helm
Design Patterns – Classical Patterns
14. ▸Descrição geral do tipo de problema que o padrão aborda:
▸Criacional:
▸Preocupado com tudo sobre a criação de objetos
▸Estrutural:
▸Preocupado com a forma como classes e objetos são compostos para formar
estruturas maiores
Design Patterns – Tipos de Padrões
16. ▸Os padrões de criação são aqueles que criam objetos para você, ao invés de
você ter que instanciar objetos diretamente. Isso dá ao seu programa mais
flexibilidade na decisão de quais objetos precisam ser criados para um
determinado caso.
▸Abstract Factory: Grupos objetos fábricas que têm um tema comum.
▸Builder *: Objetos complexos, separando construção e representação.
▸Factory Method: Cria objetos sem especificar a classe exata a ser criada.
▸Prototype: cria objetos clonando um objeto existente.
▸Singleton: Restringe a criação de objetos para uma classe em apenas uma instância.
Design Patterns – Padrões criacionais (Overview)
17. ▸Estes referem-se à composição da classe e do objeto. Eles usam a herança
para compor interfaces e definir maneiras de compor objetos para obter
novas funcionalidades.
▸Adapter: Permite que classes com interfaces incompatíveis trabalhem juntas
envolvendo sua própria interface ao redor de uma classe já existente.
▸Bridge: Desacopla uma abstração de sua implementação para que os dois possam
variar independentemente.
▸Composite *: Compõe objetos zero-ou-mais semelhantes para que possam ser
manipulados como um objeto.
▸Decorator: dinamicamente adiciona / substitui comportamento em um método
existente de um objeto
Design Patterns – Padrões estruturais (Overview)
18. ▸Facade: Fornece uma interface simplificada para um grande corpo de
código.
▸Flyweight: Reduz o custo de criar e manipular um grande número de
objetos semelhantes.
▸Proxy: Fornece um espaço reservado para outro objeto para controlar o
acesso, reduzir custos e reduzir a complexidade.
Design Patterns – Padrões estruturais (Overview)
19. ▸A maioria desses padrões de projeto está especificamente preocupada com
a comunicação entre objetos.
▸Chain of responsibility: Dedica comandos a uma cadeia de objetos de
processamento.
▸Command : Cria objetos que encapsulam ações e parâmetros.
▸Interpreter: Implementa uma linguagem especializada.
▸Iterator: Acessa os elementos de um objeto sequencialmente sem expor sua
representação subjacente.
Design Patterns – Padrões comportamentais (Overview)
20. ▸Mediator: Permite um baixo acoplamento entre as classes por ser a única classe que
tem conhecimento detalhado de seus métodos.
▸Memento: Fornece a capacidade de restaurar um objeto para seu estado anterior
(desfazer).
▸Observer: É um padrão de publicação / subscrição que permite que um número de
objetos observadores veja um evento.
▸State *: Permite que um objeto altere seu comportamento quando seu estado
interno é alterado.
▸Strategy: Permite que uma de uma família de algoritmos seja selecionada on-the-fly
e em tempo de execução.
Design Patterns – Padrões comportamentais (Overview)
21. Design Patterns – Exemplo 1 (Builder)
▸Builder: Padrão da categoria creacional
▸Intenção: Separar a construção de um objeto complexo de sua representação de
modo que /o mesmo processo de construção possa criar representações diferentes.
▸Aplicabilidade: Necessidade de construir objetos complexos em etapas.
▸Exemplos: StringBuilder (java), StringBuffer (java), Linq (dot notation em C#) e fluent
apis em gerais.
23. Design Patterns – Exemplo 2 (Composite)
▸Composite: Padrão da categoria estrutural
▸Intenção: Compor objetos em estruturas de árvore para representar hierarquias
(parte e todo). Composite permite aos clientes tratar objetos individuais e
composições de objetos de forma uniforme.
▸Aplicabilidade: Necessidade de representar objetos ora sendo como parte ora sendo
como um todo.
▸Exemplos: Container (java.awt), Component (java.awt)
25. Design Patterns – Exemplo 3 (State)
▸State: Padrão da categoria comportamental
▸Intenção: Permitir que um objeto altere seu comportamento quando seu estado
interno é alterado. O objeto aparecerá para alterar sua classe.
▸Aplicabilidade: O comportamento de um objeto depende de seu estado e ele deve
alterar seu comportamento em tempo de execução dependendo desse estado.
▸Exemplos: LifeCycle (javax.faces), ui-router (angular 1x), máquinas de estado em
geral.
27. Design Patterns - Conclusão
▸Entender o problema para encontrar a solução mais adequada
▸DRY (Don’t Repeat Yourself) – Reutização em primeiro lugar.
▸Programe sempre dirigido à interfaces e não para a implementação
▸Crie testes unitários, pois irá ajudar na abstração e a desacoplar a solução.
▸Saiba administrar a complexidade do seu código (Princípio KIS – Keep it simple)