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?

Design Patterns

  • 2.
    Palestrantes • Amanda Moraes Engenheirada 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çade 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 deChristopher 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 descreveum 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 eleestivesse 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ãode 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 ▸Umidentificador 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 elementossã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 linguagensque 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 – Gangof Four ▸Erich Gamma ▸John Vlissides ▸Ralph Johnson ▸Richard Helm Design Patterns – Classical Patterns
  • 14.
    ▸Descrição geral dotipo 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 algoritmose a atribuição de responsabilidades entre objetos. Design Patterns – Tipos de Padrões
  • 16.
    ▸Os padrões decriaçã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 umainterface 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 dessespadrõ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 umbaixo 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)
  • 28.
  • 29.
    Design Patterns ▸Referências ▸Github: https://github.com/iluwatar/java-design-patterns ▸DesignPatterns: Elements of Reusable Object- Oriented Software; Erich Gamma et al; Addison- Wesley; 1995; 978-0201633610.
  • 30.