SlideShare uma empresa Scribd logo
1 de 30
Baixar para ler offline
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)
▸O que é padrão?
Design Patterns – Pattern
Design Patterns – Pattern
▸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
▸Existem anti-patterns?
Design Patterns – Anti-patterns
+ =
▸Obs: Existiram muitos design patterns que se tornaram anti-patterns
▸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
▸"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
▸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
▸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
▸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
▸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
▸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
▸GOF – Gang of Four
▸Erich Gamma
▸John Vlissides
▸Ralph Johnson
▸Richard Helm
Design Patterns – Classical Patterns
▸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
▸Comportamental:
▸Preocupado com algoritmos e a atribuição de responsabilidades entre objetos.
Design Patterns – Tipos de Padrões
▸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)
▸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)
▸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)
▸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)
▸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)
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.
Design Patterns – Exemplo 1 (Builder)
▸UML e Código
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)
Design Patterns – Exemplo 2 (Composite)
▸UML e Código
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.
Design Patterns – Exemplo 3 (State)
▸UML e Código
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)
Design Patterns
▸Livros indicados
Design Patterns
▸Referências
▸Github: https://github.com/iluwatar/java-design-patterns
▸Design Patterns: Elements of Reusable Object- Oriented Software; Erich Gamma
et al; Addison- Wesley; 1995; 978-0201633610.
Design Patterns – Perguntas?

Mais conteúdo relacionado

Semelhante a Design Patterns

Padroes de projetos gof
Padroes de projetos gofPadroes de projetos gof
Padroes de projetos gofYan Justino
 
Design Pattern MVC – Arquitetura de Software Coesa e Flexível
Design Pattern MVC – Arquitetura de Software Coesa e FlexívelDesign Pattern MVC – Arquitetura de Software Coesa e Flexível
Design Pattern MVC – Arquitetura de Software Coesa e FlexívelRyan Padilha
 
BlingTech - Padrões de Projeto
BlingTech - Padrões de ProjetoBlingTech - Padrões de Projeto
BlingTech - Padrões de ProjetoFernando Henrique
 
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE
APSI 2   aulas  - padroes arquiteturais - camadas PROF.TARCIANEAPSI 2   aulas  - padroes arquiteturais - camadas PROF.TARCIANE
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANEFco Edilson Nascimento
 
Padrões de projetos
Padrões de projetosPadrões de projetos
Padrões de projetosGustavo Souza
 
Arquitetura Limpa @ 32º CocoaTalks BH
Arquitetura Limpa @ 32º CocoaTalks BHArquitetura Limpa @ 32º CocoaTalks BH
Arquitetura Limpa @ 32º CocoaTalks BHHugo Ferreira
 
Intro padroesprojetoadaptertemplateobserver
Intro padroesprojetoadaptertemplateobserverIntro padroesprojetoadaptertemplateobserver
Intro padroesprojetoadaptertemplateobserverEduardo Jorge
 
Padrões de projeto - Adapter, Proxy, Composite e Bridge
Padrões de projeto - Adapter, Proxy, Composite e BridgePadrões de projeto - Adapter, Proxy, Composite e Bridge
Padrões de projeto - Adapter, Proxy, Composite e BridgeLorran Pegoretti
 
DDD – Domain Driven Design
DDD – Domain Driven DesignDDD – Domain Driven Design
DDD – Domain Driven DesignÍtalo Bandeira
 
Reutilização
ReutilizaçãoReutilização
Reutilizaçãoemjorge
 
5507 os principais design patterns
5507   os principais design patterns5507   os principais design patterns
5507 os principais design patternsAndre Baltieri
 
Padrões de Projeto de Software Orientado a Objetos
Padrões de Projeto de Software Orientado a ObjetosPadrões de Projeto de Software Orientado a Objetos
Padrões de Projeto de Software Orientado a ObjetosCloves da Rocha
 
Encontrando equilíbrio do DDD enquanto sua aplicação cresce
Encontrando equilíbrio do DDD enquanto sua aplicação cresceEncontrando equilíbrio do DDD enquanto sua aplicação cresce
Encontrando equilíbrio do DDD enquanto sua aplicação cresceCarolina Karklis
 

Semelhante a Design Patterns (20)

Padroes de projetos gof
Padroes de projetos gofPadroes de projetos gof
Padroes de projetos gof
 
Design Pattern MVC – Arquitetura de Software Coesa e Flexível
Design Pattern MVC – Arquitetura de Software Coesa e FlexívelDesign Pattern MVC – Arquitetura de Software Coesa e Flexível
Design Pattern MVC – Arquitetura de Software Coesa e Flexível
 
Travalho versao final
Travalho versao finalTravalho versao final
Travalho versao final
 
UMLIntro.pptx
UMLIntro.pptxUMLIntro.pptx
UMLIntro.pptx
 
BlingTech - Padrões de Projeto
BlingTech - Padrões de ProjetoBlingTech - Padrões de Projeto
BlingTech - Padrões de Projeto
 
Design Patterns
Design PatternsDesign Patterns
Design Patterns
 
[CEFETMG][ESw] Aula 6 - Conceitos de projeto
[CEFETMG][ESw] Aula 6 - Conceitos de projeto[CEFETMG][ESw] Aula 6 - Conceitos de projeto
[CEFETMG][ESw] Aula 6 - Conceitos de projeto
 
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE
APSI 2   aulas  - padroes arquiteturais - camadas PROF.TARCIANEAPSI 2   aulas  - padroes arquiteturais - camadas PROF.TARCIANE
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE
 
Padrões de projetos
Padrões de projetosPadrões de projetos
Padrões de projetos
 
Arquitetura Limpa @ 32º CocoaTalks BH
Arquitetura Limpa @ 32º CocoaTalks BHArquitetura Limpa @ 32º CocoaTalks BH
Arquitetura Limpa @ 32º CocoaTalks BH
 
Intro padroesprojetoadaptertemplateobserver
Intro padroesprojetoadaptertemplateobserverIntro padroesprojetoadaptertemplateobserver
Intro padroesprojetoadaptertemplateobserver
 
Padrões de projeto - Adapter, Proxy, Composite e Bridge
Padrões de projeto - Adapter, Proxy, Composite e BridgePadrões de projeto - Adapter, Proxy, Composite e Bridge
Padrões de projeto - Adapter, Proxy, Composite e Bridge
 
DDD – Domain Driven Design
DDD – Domain Driven DesignDDD – Domain Driven Design
DDD – Domain Driven Design
 
Design patterns
Design patternsDesign patterns
Design patterns
 
DCI com PHP
DCI com PHPDCI com PHP
DCI com PHP
 
UMLIntro.pdf
UMLIntro.pdfUMLIntro.pdf
UMLIntro.pdf
 
Reutilização
ReutilizaçãoReutilização
Reutilização
 
5507 os principais design patterns
5507   os principais design patterns5507   os principais design patterns
5507 os principais design patterns
 
Padrões de Projeto de Software Orientado a Objetos
Padrões de Projeto de Software Orientado a ObjetosPadrões de Projeto de Software Orientado a Objetos
Padrões de Projeto de Software Orientado a Objetos
 
Encontrando equilíbrio do DDD enquanto sua aplicação cresce
Encontrando equilíbrio do DDD enquanto sua aplicação cresceEncontrando equilíbrio do DDD enquanto sua aplicação cresce
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
  • 5. ▸Existem anti-patterns? Design Patterns – Anti-patterns + = ▸Obs: Existiram muitos design patterns que se tornaram anti-patterns
  • 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
  • 15. ▸Comportamental: ▸Preocupado com algoritmos e a atribuição de responsabilidades entre objetos. 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.
  • 22. Design Patterns – Exemplo 1 (Builder) ▸UML e Código
  • 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)
  • 24. Design Patterns – Exemplo 2 (Composite) ▸UML e Código
  • 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.
  • 26. Design Patterns – Exemplo 3 (State) ▸UML e Código
  • 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)
  • 29. Design Patterns ▸Referências ▸Github: https://github.com/iluwatar/java-design-patterns ▸Design Patterns: Elements of Reusable Object- Oriented Software; Erich Gamma et al; Addison- Wesley; 1995; 978-0201633610.
  • 30. Design Patterns – Perguntas?