O documento discute design patterns em programação, focando em como eles ajudam a resolver problemas comuns no código. Diversos padrões são abordados, como Observer, Adapter, Factory, Iterator, MVC, Proxy, Singleton e Dependency Injection, cada um com suas características e usos. O texto destaca a importância de entender e aplicar esses padrões para criar sistemas testáveis, desacoplados e orientados a objetos.

1. Design Patterns
O que são e quando devem ser usados?

2. Vinícius Krolow
@krolow
http://github.com/krolow

3. Lucas Teixeira
http://github.com/loteixeira

4. NÃO é sobre design
photoshop, grids,
cores, arquitetura,
urbanismo, desenho,
isso é outra coisa...

5. é SIM sobre o seu código
é sobre como escrever
seu código para resolver
problemas comuns

6. conte me mais sobre isso...

7. vamos ter uma "SmallTalk"

8. Gang of four

9. é tudo sobre OOP
encapsulation, polymorphism, decouple, são
palavras comuns quando se fala em design
patterns

10. é uma linguagem comum entre programadores
é comum entre diferentes linguagens para resolver os
mesmos problemas

11. vamos ver como são organizados
let's take a look how they are organized...

12. Padrões Criacionais
Abstract Factory
Builder
Factory Method
Lazy Initialization
Multiton
Object Pool
Prototype
Singleton
Resource acquisition is initialization

13. Padrões Estruturais
Adapter
Composite
Bridge
Decorator
Facade
Flyweight
Front Controller
Module
Proxy

14. Padrões Comportamentais
Chain of responsibility
Command
Interpreter
Iterator
Mediator
Memento
Null object
Observer
Servant
Specification
State
Strategy
Template Method
Visitor

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. existem vários design patterns
mas cada um com um propósito especial

17. vamos para ação

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. show me CODE

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. 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. show me CODE

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. 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. show me CODE

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. 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. show me CODE

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. 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. show me CODE

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. 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. show me CODE

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. 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. show me CODE

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. 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. show me CODE

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. Tá, chega, cansei de legos...

43. ma vamo lá, só mais um pouco...
e o que isso me ajuda no fim?

44. a se tornar um OO star! m/

45. com código para orgulhar a família
●
■
testável
desacoplado
●
reutilizável
●
●
extensível
●
orientado a
legível
interfaces

46. mas.... tenha em mente que Design Patterns
não é a RESPOSTA para tudo!

47. mas que possívelmente alguém
já passou pelo mesmo
problema que você

48. design patterns estão sendo criados todos dias...

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

51. lembre é Orientação a Objetos não a Classes .
"Herança pode ser o câncer do seu código!" by Nós

52. Perguntas e Cerveja?