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

2.
História <ul><li>O nome “Design Patterns&quot; 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). </li></ul>

3.
História <ul><li>“ 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” </li></ul><ul><li>Christopher Alexander </li></ul>

4.
História <ul><li>Idealmente um padrão deve possuir as seguintes características: </li></ul><ul><ul><li>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. </li></ul></ul>

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

6.
História <ul><ul><li>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. </li></ul></ul><ul><ul><li>Abertura: um padrão deve permitir a sua extensão para níveis mais baixos de detalhe. </li></ul></ul>

7.
História <ul><ul><li>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. </li></ul></ul>

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

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

10.
História <ul><ul><li>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. </li></ul></ul>

11.
História <ul><li>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 ). </li></ul><ul><li>Nos anos seguintes Beck, Cunningham e outros seguiram com o desenvolvimento desta idéia. </li></ul>

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

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

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

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

16.
Família dos Padrões Criacionais <ul><li>Abstract Factory </li></ul><ul><ul><li>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. </li></ul></ul><ul><li>Builder </li></ul><ul><ul><li>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. </li></ul></ul>

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

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

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

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

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

22.
Família dos Padrões Estruturais <ul><li>Proxy </li></ul><ul><ul><li>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. </li></ul></ul>

23.
Família dos Padrões Comportamentais <ul><li>Chain of Responsability </li></ul><ul><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><ul><li>Command </li></ul><ul><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>

24.
Família dos Padrões Comportamentais <ul><li>Interpreter </li></ul><ul><li>Iterator </li></ul><ul><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 de estruturas internas. </li></ul></ul>

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

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

27.
Família dos Padrões Comportamentais <ul><li>Strategy </li></ul><ul><ul><li>Este padrão permite que o algoritmo possa variar independentemente dos clientes que o utilizam . </li></ul></ul><ul><li>Template Method </li></ul><ul><li>Visitor </li></ul><ul><ul><li>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. </li></ul></ul>

29.
Considerações Finais <ul><li>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. </li></ul>

30.
Considerações Finais <ul><li>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. </li></ul>

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

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