O documento descreve a história e conceitos de padrões de projeto de software. Apresenta os 23 padrões de projeto documentados no livro "Design Patterns" de 1995, divididos nas categorias criacionais, comportamentais e estruturais. Explica brevemente alguns padrões como Singleton, Factory Method, Observer, Composite e MVC.

1. Design Patterns O que é padrão? V: 1.1

2. Agenda Histórico Conceito Vários Patterns :-) Anti-Patterns :-(

3. História 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. Objetiva auxiliar o desenho de construções e cidades.

4. História 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 :-).

5. História (agora em sofware) Em 1995, um grupo de quatro profissionais escreveu e lançou o livro "Design Patterns: Elements of Reusable Object-Oriented Software" [Gamma95], um catálogo com 23 padrões de desenho (design patterns). Os autores: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Mais conhecidos como A Gangue dos Quatro (Gang Of Four ou GoF). Considerados os maiores entusiastas dos Design Patterns.

6. Conceitos 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.

7. Conceitos Uma coleção de padrões de desenho de software, que são soluções para problemas conhecidos e recorrentes no desenvolvimento de software.

8. Conceitos Ato de capturar idéias como um padrão. Ou simplesmente: Solução padrão para um problema recorrente.

9. Vantagens Eles foram provados. Os padrões refletem a experiência, conhecimento e soluções dos desenvolvedores que tiveram sucesso usando esses padrões em seus trabalhos. São reusáveis. Os padrões provêem uma solução pronta que pode ser aplicada à diferentes problemas. São expressíveis. Os padrões provêem um vocabulário comum de soluções que podem expressar muitas soluções, sucintamente.

10. Anatomia de um Pattern (forma Alexandrina) Contexto Uma ou duas sentenças que descreve o contexto de aplicação do pattern. Problema: Uma questão que ilustra o problema. Forças (motivação): Forças atuantes que requerem a solução. Apresenta a necessidade do pattern Solução: Uma ou duas sentenças que introduz a solução Descrição da Solução: Descrição detalhada.

11. Meu Primeiro Pattern :-) Precisamos desenvolver um sistema que possui como uma das classes, o SuperHomem. Sabemos que ele é a última instância da classe Kryptoniano. (Esqueçam o General Zod por enquanto :-)). Os demais que aparecem nos quadrinhos são clones (aí é outro pattern (prototype)).

12. O Problema: Criar uma classe que poderá possuir apenas uma única instância. Isso é um problema recorrente? Religiões monoteístas tem apenas um deus. Sistemas de informação tem apenas uma configuração por site. Carro tem apenas um motor. Chester tem apenas um. Usem sua imaginação...

13. Pattern Singleton Vamos ao código. (hands-on)

14. Design-Patterns (GoF)

15. Design-Patterns (GoF) Criacional Classes ou métodos construtores. Patterns: Singleton Builder Abstract Factory Factory Method Prototype

16. Design-Patterns (GoF) Comportamental Define maneira de delegar responsabilidade pelas decisões para outro objeto. Patterns: Chain of Responsability Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor

17. Design-Patterns (GoF) Estrutural Onde um problema é resolvido através de uma estrutura de objetos. Patterns: Adapter Bridge Composite Decorator Façade Flyweight Proxy

18. Regras Gerais Grande valor dado às Interfaces. Aumenta a abstração e o 'Grau de Incerteza'. Preferência à composição invés da herança. Permite várias estruturas. Maior Flexibilidade.

19. Programando contra Interfaces Conheça o protocolo (conjunto de métodos), não conheça a classe. Ex: JDBC

20. Singleton Este padrão garante a existência de apenas uma instância de uma classe, mantendo um ponto global de acesso ao seu objeto. Curiosidade: O termo vem do significado em inglês quando se resta apenas uma carta nas mãos

21. Factory Method Define uma interface para criar um objeto, mas deixa as subclasses decidir qual classe será instanciada. Define um construtor “virtual”. O operador new é considerado perigoso.

22. Factory Method

23. Factory Method

24. Prototype Especifica o tipo de objeto a ser criado com base de uma instância protótipo. Cria cópias de um objeto. O operador new é considerado perigoso.

25. Prototype

26. Prototype

27. Chain of Responsability 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. Encadear os objetos receptores, passando a solicitação ao longo da cadeia até que um objeto a trate.

28. Chain of Responsability

29. Chain of Responsability

30. Command 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. Também conhecido como Action ou Transaction.

31. Command

32. Command

33. Interpreter Usado para definição de linguagem. Define representações para gramáticas e abstrações para análise sintática. Executa (eval) uma instrução em linguagem diferente.

34. Interpreter

35. Interpreter

36. Iterator permite a "iteração" e um modo de acesso a elementos de um agregado de objetos, seqüencialmente, sem exposição das estruturas internas.

37. Iterator

38. Iterator

39. Observer 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. Permite que objetos interessados sejam avisados da mudança de estado ou outros eventos ocorrendo num outro objeto.

40. Observer

41. Observer

42. State O padrão de desenho state é usado para permitir que um objeto altere o seu comportamento quando o seu estado muda. Ao utilizar este padrão, parecerá que o objeto mudou de classe. Usa um objeto como estado.

43. State

44. State

45. Template Method Define o esqueleto de um algoritmo numa operação, passando alguns passos para as subclasses. Permite que a subclasse mude certos passos sem mudar a estrutura do algoritmo. A classe base declara “placeholders” do algoritmo e as subclasses preenchem esses “placeholders”.

46. Template Method

47. Template Method

48. Composite Composite é um padrão de projeto de software utilizado para representar estruturas de objetos agrupados hierarquicamente. Através deste padrão é possível enxergar uma "composição" de objetos como se fosse um objeto individual.

49. Composite

50. Composite

51. Decorator Anexa responsabilidades adicionais a um objeto dinamicamente. Provê um alternativa flexível às subclasses extendendo a funcionalidade. Amplia a funcionalidade através da composição.

52. Decorator

53. Decorator

54. Façade 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. Reduz as dependências em relação às características internas de uma biblioteca, trazendo flexibilidade no desenvolvimento do sistema

55. Façade

56. Façade

57. Flyweight 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. Similar à um pool.

58. Flyweight

59. Flyweight

60. Outros Patterns Não só de GoF vive o projeto

61. MVC 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). Permite que a mesma lógica de negócios possa ser acessada e visualizada por várias interfaces.

62. MVC

63. Modelo 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.

64. Controller 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.

65. View Gera a interface com usuário de modo que esta somente requisite o processamento de eventos pelo Controller.

66. MVC 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.

67. DAO Data Access Object é um componente de software que provê uma interface comum entre a aplicação e um ou mais dispositivos de armazenamento.

68. ValueObject 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. O objeto de negócio pode construir o VO, preencher seus atributos e passá-lo para o cliente.

69. ValueObject

70. IoC (Dependency Injection) 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. Esta é uma característica comum aos frameworks. http://www.javafree.org/content/view.jf?idContent=1

71. Make it run, make it right, make it fast, make it small Define a ordem e o momento da otimização de código e performance. Faça Rodar. Faça Rodar Corretamente. Faça Rodar Rápido. Faça Rodar com menos Código. “Premature optimization is the root of all evil.” - Tony Hoare

72. Anti-Patterns Sempre haverá o lado negro

73. Anti-Patterns Inspirados nos Design Patterns. Solução padrão que provê benefícios em curto prazo. Os problemas futuros sobrepõe os benefícios imediatos. Dificultam a manutenção.

74. Copy and Paste Programming É um estilo informal de programação que simplesmente copia códigos de um programa para outro. O termo vem de uma atividade comum no uso de computadores: Copiar e Colar.

75. The Golden Hammer 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. Quando a única ferramenta que se tem é um martelo, tudo lhe parece um prego.

76. Reinventing the Wheel Este não precisa de nenhuma explicação. :-b Derivação: Reinventing the square wheel Chegar a primeira versão de uma solução já existente.

77. Busy waiting/Spinning Busy waiting ou spinnig é uma técnica onde um processo checa repetidas vezes verificando se uma condição é verdadeira. Um loop infinito que desperdiça tempo da cpu para avaliar se existe algo a executar. As vezes utilizado para criar uma pausa na execução de um programa.

78. Onde encontrar mais Anti-Patterns? http://en.wikipedia.org/wiki/Anti-patterns E tem muitos? Sim, um montão deles :-)

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.