<ul><ul><li>Design Patterns </li></ul></ul><ul><ul><li>O que é padrão? </li></ul></ul>V: 1.1
Agenda <ul><li>Histórico </li></ul><ul><li>Conceito </li></ul><ul><li>Vários Patterns :-) </li></ul><ul><li>Anti-Patterns ...
História <ul><li>A origem dos Design Patterns (Padrões de Desenho) vem do trabalho de um arquiteto chamado Christopher Ale...
História <ul><li>Os patterns de Alexander procuravam prover uma fonte de  idéias provadas  para indivíduos e comunidades p...
História (agora em sofware) <ul><li>Em 1995, um grupo de quatro profissionais escreveu e lançou o livro &quot;Design Patte...
Conceitos <ul><li>Um Pattern descreve uma solução comprovada para um problema de desenho recorrente, dando ênfase particul...
Conceitos <ul><li>Uma coleção de padrões de desenho de software, que são soluções para problemas conhecidos e recorrentes ...
Conceitos <ul><li>Ato de capturar idéias como um padrão. </li></ul><ul><li>Ou simplesmente: </li></ul><ul><ul><li>Solução ...
Vantagens <ul><li>Eles foram provados. </li></ul><ul><ul><li>Os padrões refletem a experiência, conhecimento e soluções do...
Anatomia de um Pattern (forma Alexandrina) <ul><li>Contexto </li></ul><ul><ul><li>Uma ou duas sentenças que descreve o con...
Meu Primeiro Pattern :-) <ul><li>Precisamos desenvolver um sistema que possui como uma das classes, o SuperHomem. </li></u...
O Problema: <ul><li>Criar uma classe que poderá possuir apenas uma única instância. </li></ul><ul><li>Isso é um problema r...
Pattern Singleton <ul><li>Vamos ao código. </li></ul><ul><li>(hands-on) </li></ul>
Design-Patterns (GoF)
Design-Patterns (GoF) <ul><li>Criacional </li></ul><ul><ul><li>Classes ou métodos construtores. </li></ul></ul><ul><li>Pat...
Design-Patterns (GoF) <ul><li>Comportamental </li></ul><ul><ul><li>Define maneira de delegar responsabilidade pelas decisõ...
Design-Patterns (GoF) <ul><li>Estrutural </li></ul><ul><ul><li>Onde um problema é resolvido através de uma estrutura de ob...
Regras Gerais <ul><li>Grande valor dado às Interfaces. </li></ul><ul><ul><li>Aumenta a abstração e o 'Grau de Incerteza'. ...
Programando contra Interfaces <ul><li>Conheça o protocolo (conjunto de métodos), não conheça a classe. </li></ul><ul><li>E...
Singleton <ul><li>Este padrão garante a existência de apenas uma instância de uma classe, mantendo um ponto global de aces...
Factory Method <ul><li>Define uma interface para criar um objeto, mas deixa as subclasses decidir qual classe será instanc...
Factory Method
Factory Method
Prototype <ul><li>Especifica o tipo de objeto a ser criado com base de uma instância protótipo. </li></ul><ul><li>Cria cóp...
Prototype
Prototype
Chain of Responsability <ul><li>Evita o acoplamento do remetente de uma solicitação ao seu receptor, ao dar a mais de um o...
Chain of Responsability
Chain of Responsability
Command <ul><li>Encapsular uma solicitação como um objeto, desta forma permitindo parametrizar clientes com diferentes sol...
Command
Command
Interpreter <ul><li>Usado para definição de linguagem. </li></ul><ul><li>Define representações para gramáticas e abstraçõe...
Interpreter
Interpreter
Iterator <ul><li>permite a &quot;iteração&quot; e um modo de acesso a elementos de um agregado de objetos, seqüencialmente...
Iterator
Iterator
Observer <ul><li>Define uma dependência um-para-muitos entre objetos de modo que quando um objeto muda o estado, todos seu...
Observer
Observer
State <ul><li>O padrão de desenho state é usado para permitir que um objeto altere o seu comportamento quando o seu estado...
State
State
Template Method <ul><li>Define o esqueleto de um algoritmo numa operação, passando alguns passos para as subclasses.  </li...
Template Method
Template Method
Composite <ul><li>Composite é um padrão de projeto de software utilizado para representar estruturas de objetos agrupados ...
Composite
Composite
Decorator <ul><li>Anexa responsabilidades adicionais a um objeto dinamicamente. </li></ul><ul><li>Provê um alternativa fle...
Decorator
Decorator
Façade <ul><li>Em padrões de projeto de software, um façade é um objeto que disponibiliza uma interface para uma grande qu...
Façade
Façade
Flyweight <ul><li>Flyweight é uma padrão de projeto de software que define como compartilhar objetos para que os mesmos po...
Flyweight
Flyweight
Outros Patterns Não só de GoF vive o projeto
MVC <ul><li>Model View Controller ou Modelo-Visão-Controlador é um padrão de arquitetura de aplicações que visa separar a ...
MVC
Modelo <ul><li>Implementa o modelo representando a estrutura de baixo nivel do projeto, podendo ser o modelo objeto-relaci...
Controller <ul><li>Implementa a camada respónsavel pelo gerenciamentos de eventos no projeto, tais como cliques do usuario...
View <ul><li>Gera a interface com usuário de modo que esta somente requisite o processamento de eventos pelo Controller. <...
MVC <ul><li>Para uma implemetação correta, as camadas Model, Controller e View devem ser implementadas de forma que a inve...
DAO <ul><li>Data Access Object é um componente de software que provê uma interface comum entre a aplicação e um ou mais di...
ValueObject <ul><li>Alguns métodos expostos por componentes de negócio retornam dados para o cliente. E as vezes são feita...
ValueObject
IoC (Dependency Injection) <ul><li>Inversion of Control (IoC) é o nome dado ao padrão de desenvolvimento de programas de c...
Make it run, make it right, make it fast, make it small <ul><li>Define a ordem e o momento da otimização de código e perfo...
Anti-Patterns Sempre haverá o lado negro
Anti-Patterns <ul><li>Inspirados nos Design Patterns. </li></ul><ul><li>Solução padrão que provê benefícios em curto prazo...
Copy and Paste Programming <ul><li>É um estilo informal de programação que simplesmente copia códigos de um programa para ...
The Golden Hammer <ul><li>Uso excessivo ou obsessivo de uma tecnologia ou ferramenta leva ao Golden Hammer. Equipes ou ind...
Reinventing the Wheel <ul><li>Este não precisa de nenhuma explicação. :-b </li></ul><ul><li>Derivação: </li></ul><ul><ul><...
Busy waiting/Spinning <ul><li>Busy waiting ou spinnig é uma técnica onde um processo checa repetidas vezes verificando se ...
Onde encontrar mais Anti-Patterns? <ul><li>http://en.wikipedia.org/wiki/Anti-patterns </li></ul><ul><li>E tem muitos? </li...
Agradecimentos Ao agradecimento especial ao Wikipedia, e a Vince Hustom que criou o melhor site sobre patterns que já conh...
Upcoming SlideShare
Loading in...5
×

Design Patterns

5,137

Published on

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,137
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
20
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

Transcript of "Design Patterns"

  1. 1. <ul><ul><li>Design Patterns </li></ul></ul><ul><ul><li>O que é padrão? </li></ul></ul>V: 1.1
  2. 2. Agenda <ul><li>Histórico </li></ul><ul><li>Conceito </li></ul><ul><li>Vários Patterns :-) </li></ul><ul><li>Anti-Patterns :-( </li></ul>
  3. 3. História <ul><li>A origem dos Design Patterns (Padrões de Desenho) vem do trabalho de um arquiteto chamado Christopher Alexander, no final da década de 70. Ele escreveu dois livros, inicialmente, A Pattern Language [Alex77] e A Timeless Way of Building [Alex79], nos quais ele exemplificava o uso e descrevia seu raciocínio para documentar os padrões. </li></ul><ul><li>Objetiva auxiliar o desenho de construções e cidades. </li></ul>
  4. 4. História <ul><li>Os patterns de Alexander procuravam prover uma fonte de idéias provadas para indivíduos e comunidades para serem usadas em construções, mostrando assim o quanto belo, confortável e flexível os ambientes podem ser construídos :-). </li></ul>
  5. 5. História (agora em sofware) <ul><li>Em 1995, um grupo de quatro profissionais escreveu e lançou o livro &quot;Design Patterns: Elements of Reusable Object-Oriented Software&quot; [Gamma95], um catálogo com 23 padrões de desenho (design patterns). </li></ul><ul><li>Os autores: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Mais conhecidos como A Gangue dos Quatro (Gang Of Four ou GoF). </li></ul><ul><li>Considerados os maiores entusiastas dos Design Patterns. </li></ul>
  6. 6. Conceitos <ul><li>Um Pattern descreve uma solução comprovada para um problema de desenho recorrente, dando ênfase particular no contexto e forçando a aproximação do problema, e as conseqüências e o impacto de sua solução. </li></ul>
  7. 7. Conceitos <ul><li>Uma coleção de padrões de desenho de software, que são soluções para problemas conhecidos e recorrentes no desenvolvimento de software. </li></ul>
  8. 8. Conceitos <ul><li>Ato de capturar idéias como um padrão. </li></ul><ul><li>Ou simplesmente: </li></ul><ul><ul><li>Solução padrão para um problema recorrente. </li></ul></ul>
  9. 9. Vantagens <ul><li>Eles foram provados. </li></ul><ul><ul><li>Os padrões refletem a experiência, conhecimento e soluções dos desenvolvedores que tiveram sucesso usando esses padrões em seus trabalhos. </li></ul></ul><ul><li>São reusáveis. </li></ul><ul><ul><li>Os padrões provêem uma solução pronta que pode ser aplicada à diferentes problemas. </li></ul></ul><ul><li>São expressíveis. </li></ul><ul><ul><li>Os padrões provêem um vocabulário comum de soluções que podem expressar muitas soluções, sucintamente. </li></ul></ul>
  10. 10. Anatomia de um Pattern (forma Alexandrina) <ul><li>Contexto </li></ul><ul><ul><li>Uma ou duas sentenças que descreve o contexto de aplicação do pattern. </li></ul></ul><ul><li>Problema: </li></ul><ul><ul><li>Uma questão que ilustra o problema. </li></ul></ul><ul><li>Forças (motivação): </li></ul><ul><ul><li>Forças atuantes que requerem a solução. </li></ul></ul><ul><ul><li>Apresenta a necessidade do pattern </li></ul></ul><ul><li>Solução: </li></ul><ul><ul><li>Uma ou duas sentenças que introduz a solução </li></ul></ul><ul><li>Descrição da Solução: </li></ul><ul><ul><li>Descrição detalhada. </li></ul></ul>
  11. 11. Meu Primeiro Pattern :-) <ul><li>Precisamos desenvolver um sistema que possui como uma das classes, o SuperHomem. </li></ul><ul><li>Sabemos que ele é a última instância da classe Kryptoniano. (Esqueçam o General Zod por enquanto :-)). </li></ul><ul><li>Os demais que aparecem nos quadrinhos são clones (aí é outro pattern (prototype)). </li></ul>
  12. 12. O Problema: <ul><li>Criar uma classe que poderá possuir apenas uma única instância. </li></ul><ul><li>Isso é um problema recorrente? </li></ul><ul><ul><li>Religiões monoteístas tem apenas um deus. </li></ul></ul><ul><ul><li>Sistemas de informação tem apenas uma configuração por site. </li></ul></ul><ul><ul><li>Carro tem apenas um motor. </li></ul></ul><ul><ul><li>Chester tem apenas um. </li></ul></ul><ul><ul><li>Usem sua imaginação... </li></ul></ul>
  13. 13. Pattern Singleton <ul><li>Vamos ao código. </li></ul><ul><li>(hands-on) </li></ul>
  14. 14. Design-Patterns (GoF)
  15. 15. Design-Patterns (GoF) <ul><li>Criacional </li></ul><ul><ul><li>Classes ou métodos construtores. </li></ul></ul><ul><li>Patterns: </li></ul><ul><ul><li>Singleton </li></ul></ul><ul><ul><li>Builder </li></ul></ul><ul><ul><li>Abstract Factory </li></ul></ul><ul><ul><li>Factory Method </li></ul></ul><ul><ul><li>Prototype </li></ul></ul>
  16. 16. Design-Patterns (GoF) <ul><li>Comportamental </li></ul><ul><ul><li>Define maneira de delegar responsabilidade pelas decisões para outro objeto. </li></ul></ul><ul><li>Patterns: </li></ul><ul><ul><li>Chain of Responsability </li></ul></ul><ul><ul><li>Command </li></ul></ul><ul><ul><li>Interpreter </li></ul></ul><ul><ul><li>Iterator </li></ul></ul><ul><ul><li>Mediator </li></ul></ul><ul><ul><li>Memento </li></ul></ul><ul><ul><li>Observer </li></ul></ul><ul><ul><li>State </li></ul></ul><ul><ul><li>Strategy </li></ul></ul><ul><ul><li>Template Method </li></ul></ul><ul><ul><li>Visitor </li></ul></ul>
  17. 17. Design-Patterns (GoF) <ul><li>Estrutural </li></ul><ul><ul><li>Onde um problema é resolvido através de uma estrutura de objetos. </li></ul></ul><ul><li>Patterns: </li></ul><ul><ul><li>Adapter </li></ul></ul><ul><ul><li>Bridge </li></ul></ul><ul><ul><li>Composite </li></ul></ul><ul><ul><li>Decorator </li></ul></ul><ul><ul><li>Façade </li></ul></ul><ul><ul><li>Flyweight </li></ul></ul><ul><ul><li>Proxy </li></ul></ul>
  18. 18. Regras Gerais <ul><li>Grande valor dado às Interfaces. </li></ul><ul><ul><li>Aumenta a abstração e o 'Grau de Incerteza'. </li></ul></ul><ul><li>Preferência à composição invés da herança. </li></ul><ul><ul><li>Permite várias estruturas. </li></ul></ul><ul><ul><li>Maior Flexibilidade. </li></ul></ul>
  19. 19. Programando contra Interfaces <ul><li>Conheça o protocolo (conjunto de métodos), não conheça a classe. </li></ul><ul><li>Ex: </li></ul><ul><ul><li>JDBC </li></ul></ul>
  20. 20. Singleton <ul><li>Este padrão garante a existência de apenas uma instância de uma classe, mantendo um ponto global de acesso ao seu objeto. </li></ul><ul><li>Curiosidade: O termo vem do significado em inglês quando se resta apenas uma carta nas mãos </li></ul>
  21. 21. Factory Method <ul><li>Define uma interface para criar um objeto, mas deixa as subclasses decidir qual classe será instanciada. </li></ul><ul><li>Define um construtor “virtual”. </li></ul><ul><li>O operador new é considerado perigoso. </li></ul>
  22. 22. Factory Method
  23. 23. Factory Method
  24. 24. Prototype <ul><li>Especifica o tipo de objeto a ser criado com base de uma instância protótipo. </li></ul><ul><li>Cria cópias de um objeto. </li></ul><ul><li>O operador new é considerado perigoso. </li></ul>
  25. 25. Prototype
  26. 26. Prototype
  27. 27. Chain of Responsability <ul><li>Evita o acoplamento do remetente de uma solicitação ao seu receptor, ao dar a mais de um objeto a oportunidade de tratar a solicitação. </li></ul><ul><li>Encadear os objetos receptores, passando a solicitação ao longo da cadeia até que um objeto a trate. </li></ul>
  28. 28. Chain of Responsability
  29. 29. Chain of Responsability
  30. 30. Command <ul><li>Encapsular uma solicitação como um objeto, desta forma permitindo parametrizar clientes com diferentes solicitações, enfileirar ou fazer o registro (log) de solicitações e suportar operações que podem ser desfeitas. </li></ul><ul><li>Também conhecido como Action ou Transaction. </li></ul>
  31. 31. Command
  32. 32. Command
  33. 33. Interpreter <ul><li>Usado para definição de linguagem. </li></ul><ul><li>Define representações para gramáticas e abstrações para análise sintática. </li></ul><ul><li>Executa (eval) uma instrução em linguagem diferente. </li></ul>
  34. 34. Interpreter
  35. 35. Interpreter
  36. 36. Iterator <ul><li>permite a &quot;iteração&quot; e um modo de acesso a elementos de um agregado de objetos, seqüencialmente, sem exposição das estruturas internas. </li></ul>
  37. 37. Iterator
  38. 38. Iterator
  39. 39. Observer <ul><li>Define uma dependência um-para-muitos entre objetos de modo que quando um objeto muda o estado, todos seus dependentes sejam notificados e atualizados automaticamente. </li></ul><ul><li>Permite que objetos interessados sejam avisados da mudança de estado ou outros eventos ocorrendo num outro objeto. </li></ul>
  40. 40. Observer
  41. 41. Observer
  42. 42. State <ul><li>O padrão de desenho state é usado para permitir que um objeto altere o seu comportamento quando o seu estado muda. </li></ul><ul><li>Ao utilizar este padrão, parecerá que o objeto mudou de classe. </li></ul><ul><li>Usa um objeto como estado. </li></ul>
  43. 43. State
  44. 44. State
  45. 45. Template Method <ul><li>Define o esqueleto de um algoritmo numa operação, passando alguns passos para as subclasses. </li></ul><ul><li>Permite que a subclasse mude certos passos sem mudar a estrutura do algoritmo. </li></ul><ul><li>A classe base declara “placeholders” do algoritmo e as subclasses preenchem esses “placeholders”. </li></ul>
  46. 46. Template Method
  47. 47. Template Method
  48. 48. Composite <ul><li>Composite é um padrão de projeto de software utilizado para representar estruturas de objetos agrupados hierarquicamente. </li></ul><ul><li>Através deste padrão é possível enxergar uma &quot;composição&quot; de objetos como se fosse um objeto individual. </li></ul>
  49. 49. Composite
  50. 50. Composite
  51. 51. Decorator <ul><li>Anexa responsabilidades adicionais a um objeto dinamicamente. </li></ul><ul><li>Provê um alternativa flexível às subclasses extendendo a funcionalidade. </li></ul><ul><li>Amplia a funcionalidade através da composição. </li></ul>
  52. 52. Decorator
  53. 53. Decorator
  54. 54. Façade <ul><li>Em padrões de projeto de software, um façade é um objeto que disponibiliza uma interface para uma grande quantidade de funcionalidades de uma API, por exemplo. </li></ul><ul><li>Reduz as dependências em relação às características internas de uma biblioteca, trazendo flexibilidade no desenvolvimento do sistema </li></ul>
  55. 55. Façade
  56. 56. Façade
  57. 57. Flyweight <ul><li>Flyweight é uma padrão de projeto de software que define como compartilhar objetos para que os mesmos possam ser usados em vários locais ao mesmo tempo, sendo assim, um Flyweight atua independentemente em cada local. </li></ul><ul><li>Similar à um pool. </li></ul>
  58. 58. Flyweight
  59. 59. Flyweight
  60. 60. Outros Patterns Não só de GoF vive o projeto
  61. 61. MVC <ul><li>Model View Controller ou Modelo-Visão-Controlador é um padrão de arquitetura de aplicações que visa separar a lógica da aplicação (Model), da interface do usuário (View) e do fluxo da aplicação (Controller). </li></ul><ul><li>Permite que a mesma lógica de negócios possa ser acessada e visualizada por várias interfaces. </li></ul>
  62. 62. MVC
  63. 63. Modelo <ul><li>Implementa o modelo representando a estrutura de baixo nivel do projeto, podendo ser o modelo objeto-relacional que implementa a camada de dados, e ou num caso de MVC de Interface poderia guardar informações de estado dos controles. </li></ul>
  64. 64. Controller <ul><li>Implementa a camada respónsavel pelo gerenciamentos de eventos no projeto, tais como cliques do usuario, chamando a camada Model para processar os eventos, tambem pode manter informações de estado do usuario na aplicação. </li></ul>
  65. 65. View <ul><li>Gera a interface com usuário de modo que esta somente requisite o processamento de eventos pelo Controller. </li></ul>
  66. 66. MVC <ul><li>Para uma implemetação correta, as camadas Model, Controller e View devem ser implementadas de forma que a inversão da ordem não acarrete problemas por dependência, ou seja, a camada de interface (View) depende de controle (Controller) que acessa um Modelo (Model), mas nunca o inverso. </li></ul>
  67. 67. DAO <ul><li>Data Access Object é um componente de software que provê uma interface comum entre a aplicação e um ou mais dispositivos de armazenamento. </li></ul>
  68. 68. ValueObject <ul><li>Alguns métodos expostos por componentes de negócio retornam dados para o cliente. E as vezes são feitas várias chamadas para pegar todos os valores, e com o VO, uma única chamada de método é usada para enviar e recuperar um VO. </li></ul><ul><li>O objeto de negócio pode construir o VO, preencher seus atributos e passá-lo para o cliente. </li></ul>
  69. 69. ValueObject
  70. 70. IoC (Dependency Injection) <ul><li>Inversion of Control (IoC) é o nome dado ao padrão de desenvolvimento de programas de computadores onde a seqüência (controle) de chamadas dos métodos não é determinada pelo programador. Este controle é delegado a uma infraestrutura de software muitas vezes chamada de container. </li></ul><ul><li>Esta é uma característica comum aos frameworks. </li></ul><ul><li>http://www.javafree.org/content/view.jf?idContent=1 </li></ul>
  71. 71. Make it run, make it right, make it fast, make it small <ul><li>Define a ordem e o momento da otimização de código e performance. </li></ul><ul><li>Faça Rodar. </li></ul><ul><li>Faça Rodar Corretamente. </li></ul><ul><li>Faça Rodar Rápido. </li></ul><ul><li>Faça Rodar com menos Código. </li></ul><ul><li>“Premature optimization is the root of all evil.” - Tony Hoare </li></ul>
  72. 72. Anti-Patterns Sempre haverá o lado negro
  73. 73. Anti-Patterns <ul><li>Inspirados nos Design Patterns. </li></ul><ul><li>Solução padrão que provê benefícios em curto prazo. </li></ul><ul><li>Os problemas futuros sobrepõe os benefícios imediatos. </li></ul><ul><li>Dificultam a manutenção. </li></ul>
  74. 74. Copy and Paste Programming <ul><li>É um estilo informal de programação que simplesmente copia códigos de um programa para outro. </li></ul><ul><li>O termo vem de uma atividade comum no uso de computadores: Copiar e Colar. </li></ul>
  75. 75. The Golden Hammer <ul><li>Uso excessivo ou obsessivo de uma tecnologia ou ferramenta leva ao Golden Hammer. Equipes ou indivíduos com conhecimento numa tecnologia particular tende a usar esse mesmo conhecimento em outros projetos onde outra tecnologia seria mais adequada. </li></ul><ul><li>Quando a única ferramenta que se tem é um martelo, tudo lhe parece um prego. </li></ul>
  76. 76. Reinventing the Wheel <ul><li>Este não precisa de nenhuma explicação. :-b </li></ul><ul><li>Derivação: </li></ul><ul><ul><li>Reinventing the square wheel </li></ul></ul><ul><ul><ul><li>Chegar a primeira versão de uma solução já existente. </li></ul></ul></ul>
  77. 77. Busy waiting/Spinning <ul><li>Busy waiting ou spinnig é uma técnica onde um processo checa repetidas vezes verificando se uma condição é verdadeira. </li></ul><ul><li>Um loop infinito que desperdiça tempo da cpu para avaliar se existe algo a executar. </li></ul><ul><li>As vezes utilizado para criar uma pausa na execução de um programa. </li></ul>
  78. 78. Onde encontrar mais Anti-Patterns? <ul><li>http://en.wikipedia.org/wiki/Anti-patterns </li></ul><ul><li>E tem muitos? </li></ul><ul><ul><li>Sim, um montão deles :-) </li></ul></ul>
  79. 79. Agradecimentos Ao agradecimento especial ao Wikipedia, e a Vince Hustom que criou o melhor site sobre patterns que já conheci. Sem eles, não teria terminado isso a tempo.

×