Design patterns

1,728 views

Published on

Palestra sobre Design Patterns, abordando alguns principios de orientação a objetos e alguns design patterns.

Published in: Technology

Design patterns

  1. 1. Design PatternsO que são e quando devem ser usados?
  2. 2. Vinícius Krolow@krolowhttp://github.com/krolow
  3. 3. Lucas Teixeirahttp://github.com/loteixeira
  4. 4. NÃO é sobre design photoshop, grids, cores, arquitetura, urbanismo, desenho, isso é outra coisa...
  5. 5. é SIM sobre o seu códigoé sobre como escreverseu código para resolver problemas comuns
  6. 6. conte me mais sobre isso...
  7. 7. vamos ter uma "SmallTalk"
  8. 8. Gang of four
  9. 9. é tudo sobre OOP encapsulation, polymorphism, decouple, são palavras comuns quando se fala em design patterns
  10. 10. é uma linguagem comum entre programadores é comum entre diferentes linguagens para resolver os mesmos problemas
  11. 11. vamos ver como são organizadoslets take a look how they are organized...
  12. 12. Padrões Criacionais Abstract Factory Builder Factory Method Lazy Initialization Multiton Object Pool Prototype Singleton Resource acquisition is initialization
  13. 13. Padrões Estruturais Adapter Composite Bridge Decorator Facade Flyweight Front Controller Module Proxy
  14. 14. Padrões Comportamentais Chain of responsibility Command Interpreter Iterator Mediator Memento Null object Observer Servant Specification State Strategy Template Method Visitor
  15. 15. Padrões Concorrentes Active Object Balking Binding properties Double-checked locking Event-based asynchronous Guarded suspension Lock Messaging design pattern (MDP) Monitor object Reactor Read-write lock Scheduler Thread pool Thread-specific storage
  16. 16. existem vários design patterns mas cada um com um propósito especial
  17. 17. vamos para ação
  18. 18. Observer "O padrão Observer define uma dependência de um-para-muitos entre objetos, onde os observadores serão notificados sobre mudanças no estado interno do objeto central."
  19. 19. show me CODE
  20. 20. Resumão ● Acoplamento fraco; ● Possui implementação nativa em várias linguagens modernas; ● Normalmente usado com o padrão MVC para a comunicação entre suas camadas; ● Auxilia na comunicação de objetos distantes; ● É Async provavelmente tem ele!
  21. 21. Adapter "O padrão Adapter (também chamado de Wrapper), é usado para conectar diferentes interfaces de forma consistente. Ele provê uma interface compatível com o código-cliente usando internamente a interface original."
  22. 22. show me CODE
  23. 23. Resumão ● Mesmo princípio dos adaptadores de tomadas elétricas; ● É uma caixa preta capaz processor um input para produzir o output desejado; ● Facilita a conversão de tipos e a integração entre diferentes bibliotecas.
  24. 24. Factory "O padrão Factory é responsável pela criação de objetos. Ele pode fornecer uma interface para criação de famílias de objetos sem a necessidade de especificar sua classe concreta"
  25. 25. show me CODE
  26. 26. Resumão ● Comum em bibliotecas de GUI - onde todos elementos possuem a mesma interface, embora o comportamento interno seja particular a cada um ● É normal aparecer junto de outros padrões de projeto (strategy, dependency injection, etc) ● Auxilia na implementação de testes automatizados ● É o cara para criar objetos dinâmicamente!
  27. 27. Iterator "O padrão Iterator permite a iteração entre os elementos de uma coleção qualquer, sem levar em consideração sua implementação e/ou como esses dados são armazenados."
  28. 28. show me CODE
  29. 29. Resumão ● Interface única e simplificada para iterar sobre todos elementos de uma coleção ● A estrutura interna, usada para armazenar os itens da coleção, torna-se irrelevante para o programador-usuário ● Possibilita a criação de Coleção de Objetos ao invês de uso de tipos nativos (array, map);
  30. 30. MVC "Model-view-controller é um padrão de projeto que visa modularizar o sistema em três partes independentes: model (dados/informação), controller (lógica da aplicação) e view (interação com o usuário)."
  31. 31. show me CODE
  32. 32. Resumão ● Separa as camadas de negócio da sua aplicação; ● Foi idealizado para lidar com pequenas camadas! ● Mal compreendido pela sociedade programadora!
  33. 33. Proxy "Um proxy, em sua forma mais geral, é uma classe que funciona como uma interface para outra classe. A classe proxy poderia conectar-se a qualquer coisa: uma conexão de rede, um objeto grande em memória, um arquivo, ou algum recurso que é difícil ou impossível de ser duplicado." Wikipédia
  34. 34. show me CODE
  35. 35. Resumão ● LazyLoad é com ele! ● Auxilia acesso remoto de classes; ● Operações custosas, vão começar a custar barato :) ● Null pattern pode ser com ele também!
  36. 36. Singleton "O Singleton é uma classe de uma instância única com um ponto de acesso global. Seu objetivo é ser um objeto "solitário", independente do ciclo de vida da aplicação."
  37. 37. show me CODE
  38. 38. Resumão ● Não é o mesmo que uma classe com métodos estáticos ● Classe de um único objeto ● Amplamente usada com bibliotecas de logging/debugging ● Controverso, muitas vezes considerado um anti-pattern ● É um inferno para testar!
  39. 39. Dependecy Injection "O modelo isola a "lógica" (A lógica da aplicação) da interface do usuário (Inserir e exibir dados), permitindo desenvolver, editar e testar separadamente cada parte." Wikipédia
  40. 40. show me CODE
  41. 41. Resumão ● Esse cara sou eu (DI)! ● Chega a nem ser um padrão de tão simples! ● Torna seu código testável e auxilia no desacoplamento do código (avoid no new) ● DIC ajudam na instância de objetos com multiplas depêndecias (aninhados) ●
  42. 42. Tá, chega, cansei de legos...
  43. 43. ma vamo lá, só mais um pouco... e o que isso me ajuda no fim?
  44. 44. a se tornar um OO star! m/
  45. 45. com código para orgulhar a família ● ■ testáveldesacoplado ● reutilizável ● ● extensível ● orientado a legível interfaces
  46. 46. mas.... tenha em mente que Design Patternsnão é a RESPOSTA para tudo!
  47. 47. mas que possívelmente alguémjá passou pelo mesmoproblema que você
  48. 48. design patterns estão sendo criados todos dias...
  49. 49. você também pode criar os seus! Nome: Hack Thursday Exemplo: Apresentação de Hoje Contexto: Aplicável todas as quintas Problema: Sede de "conhecimento" Solução: Vir todas as quintas
  50. 50. lembre é Orientação a Objetos não a Classes . "Herança pode ser o câncer do seu código!" by Nós
  51. 51. Perguntas e Cerveja?

×