O documento descreve a história e conceitos dos padrões de projeto orientados a objetos. Christopher Alexander cunhou o termo "padrões de projeto" para descrever soluções comuns a problemas recorrentes. Os padrões GoF tornaram-se populares em 1995 e descrevem padrões criacionais, estruturais e comportamentais.

1. Padrões de Design Orientado a Objetos Design Patterns

2. História O nome “Design Patterns" foi cunhado por Christopher Alexander quando ele propôs a criação de catálogos de padrões para arquitetura em seu livro: “ A Pattern Language: Towns, Buildings, Construction ”(1977).

3. História “ Cada padrão descreve um problema que ocorre freqüentemente em seu ambiente, e então descreve o cerne da solução para aquele problema, de um modo tal que você pode usar esta solução milhões de vezes, sem nunca fazer a mesma coisa repetida” Christopher Alexander

4. História Idealmente um padrão deve possuir as seguintes características: Encapsulamento: um padrão encapsula um problema/solução bem definido. Ele deve ser independente, específico e formulado de maneira a ficar claro onde ele se aplica.

5. História Generalidade: todo padrão deve permitir a construção de outras realizações a partir deste padrão. Abstração: os padrões representam abstrações da experiência empírica ou do conhecimento cotidiano.

6. História Equilíbrio: quando um padrão é utilizado em uma aplicação, o equilíbrio dá a razão, relacionada com cada uma das restrições envolvidas, para cada passo do projeto. Abertura: um padrão deve permitir a sua extensão para níveis mais baixos de detalhe.

7. História Combinatoriedade: os padrões são relacionados hierarquicamente. Padrões de alto nível podem ser compostos ou relacionados com padrões que endereçam problemas de nível mais baixo.

8. História Em sua obra, Alexander estabeleceu que um padrão deve ser descrito em cinco partes: Nome: uma descrição da solução, mais do que do problema ou do contexto. Exemplo: uma ou mais figuras, diagramas ou descrições que ilustrem um protótipo de aplicação.

9. História Contexto: a descrição das situações sob as quais o padrão se aplica. Problema: uma descrição das forças e restrições envolvidos e como elas interagem.

10. História Solução: relacionamentos estáticos e regras dinâmicas descrevendo como construir artefatos de acordo com o padrão, freqüentemente citando variações e formas de ajustar a solução segundo as circunstâncias. Inclui referências a outras soluções e o relacionamento com outros padrões de nível mais baixo ou mais alto.

11. História A partir dos conceitos criados por Alexander, Kent Beck e Ward Cunningham propuseram os primeiros padrões de projeto para a área da ciência da computação ( Construção de janelas na linguagem Smalltalk, 1988 ). Nos anos seguintes Beck, Cunningham e outros seguiram com o desenvolvimento desta idéia.

12. História Em 1995 o movimento ao redor de padrões de projeto ganhou popularidade com o livro: “ Design Patterns: Elements of Reusable Object-Oriented Software ” . Os autores desse livro são Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, conhecidos como a "Gangue dos Quatro" (Gang of Four) ou simplesmente "GoF".

13. Porque Utilizar Design Patterns? Criação de soluções de software: Elegantes Simples Reutilizáveis Fácil manutenção

14. Padrões GoF Os padrões GoF são organizados nas seguintes famílias: Criacionais Tornam um sistema independente de como seus objetos são criados, compostos e representados

15. Padrões GoF Estruturais Tratam de compor classes e objetos para formar estruturas grandes e complexas Comportamentais Tratam de algoritmos e como atribuir responsabilidades entre objetos

16. Família dos Padrões Criacionais Abstract Factory Permite a criação de famílias de objetos relacionados ou dependentes, através de uma única interface e sem que a classe concreta seja especificada. Builder permite a separação da construção de um objeto complexo da sua representação, de forma que o mesmo processo de construção possa criar diferentes representações.

17. Família dos Padrões Criacionais Factory Method Fornece uma interface para criação de famílias de objetos relacionados ou dependentes, sem especificar suas classes concretas. Prototype Permite a criação de objetos a partir de um modelo original, ou protótipo (clonar objetos instanciados em memória).

18. Família dos Padrões Criacionais Singleton Permite que uma classe possua apenas uma instância. Isso permite um único ponto global de acesso á essa instância.

19. Família dos Padrões Estruturais Adapter Permite que classes com interfaces incompatíveis possam interagir. Bridge utilizado quando é desejável que uma interface (abstração) possa variar independentemente das suas implementações.

20. Família dos Padrões Estruturais Composite Utilizado para representar um objeto que é constituído pela composição de objetos similares a ele. Decorator Utilizado para adicionar responsabilidades aos objetos dinamicamente.

21. Família dos Padrões Estruturais Façade disponibiliza uma interface para uma grande quantidade de funcionalidades de uma API Flyweight apropriado quando vários objetos devem ser manipulados, e esses não suportam dados adicionais.

22. Família dos Padrões Estruturais Proxy Encapsula um objeto através de um outro objeto que possui a mesma interface, de forma que o segundo objeto, conhecido como “ Proxy ”, controla o acesso ao primeiro, que é o objeto real.

23. Família dos Padrões Comportamentais 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 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.

24. Família dos Padrões Comportamentais Interpreter Iterator permite a "iteração" e um modo de acesso a elementos de um agregado de objetos, seqüencialmente, sem exposição de estruturas internas.

25. Família dos Padrões Comportamentais Mediator Desacopla e gerencia as colaborações entre um grupo de objetos. Memento Define como salvar o estado de uma instância de uma classe e restaurá-la depois.

26. Família dos Padrões Comportamentais Observer Permite que quando um objeto mude seu estado, todos seus dependentes sejam notificados e atualizados automaticamente. State Permite que um objeto altere o seu comportamento quando o seu estado muda.

27. Família dos Padrões Comportamentais Strategy Este padrão permite que o algoritmo possa variar independentemente dos clientes que o utilizam . Template Method Visitor permite definir novas operações sem alterar as classes dos elementos sobre os quais opera. Adiciona funções polimórficas a uma classe de maneira não invasiva.

29. Considerações Finais Os padrões de projeto não devem ser vistos como a salvação universal para o problema do desenvolvimento de software nem ser posto de lado como uma coisa inútil. Eles apenas fornecem uma relação de soluções comuns que são usadas no mundo real das aplicações comerciais, soluções que já foram provadas e aprovadas em diferentes projetos de software.

30. Considerações Finais Conhecer os padrões de projeto pode ser muito interessante mas saber como aplicá-los aos seus projetos é o que realmente vai fazer a diferença.

31. Bibliografia Enterprise Solution Patterns Using Microsoft .NET, Microsoft, 2007 Introduction to Design Patterns in C#, James W Cooper, 2002 Core J2EE Patterns, Alur, Crupi, Malks, 2004

32. Bibliografia Wikipedia http://en.wikipedia.org/wiki/Christopher_Alexander# Architecture http://pt.wikipedia.org/wiki/Padr%C3%B5es_ de_projeto_de_software http://en.wikipedia.org/wiki/A_Pattern_Language