1.
<ul><ul><li>Design Patterns </li></ul></ul><ul><ul><li>O que é padrão? </li></ul></ul>V: 1.1

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Pattern Singleton <ul><li>Vamos ao código. </li></ul><ul><li>(hands-on) </li></ul>

14.
Design-Patterns (GoF)

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.
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.
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.
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.
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.
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.
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.
Factory Method

23.
Factory Method

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.
Prototype

26.
Prototype

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.
Chain of Responsability

29.
Chain of Responsability

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.
Command

32.
Command

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.
Interpreter

35.
Interpreter

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.
Iterator

38.
Iterator

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.
Observer

41.
Observer

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.
State

44.
State

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.
Template Method

47.
Template Method

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.
Composite

50.
Composite

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.
Decorator

53.
Decorator

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.
Façade

56.
Façade

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.
Flyweight

59.
Flyweight

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

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

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.
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.
View <ul><li>Gera a interface com usuário de modo que esta somente requisite o processamento de eventos pelo Controller. </li></ul>

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.
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.
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.
ValueObject

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.
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.
Anti-Patterns Sempre haverá o lado negro

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