Desmistificando Design Patterns
•Transferir como PPTX, PDF•
0 gostou•214 visualizações
O documento apresenta Maicon Heck, um desenvolvedor .NET com 10 anos de experiência. Ele irá falar sobre Design Patterns, explicando os problemas da síndrome do "isso eu já sei" em programação orientada a objetos, as categorias e padrões mais comuns de Design Patterns como Strategy, Factory Method e Abstract Factory, e mostrar exemplos reais de implementação desses padrões.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Desmistificando Design Patterns
Semelhante a Desmistificando Design Patterns (20)
Desmistificando Design Patterns
- 2. QUEM SOU? Desenvolvedor .NET há 10 anos. Full-Stack na CWI Software. “Praticando refactoring cheguei à conclusão de que qualidade se obtém com código limpo e testado, e produtividade se obtém com reuso.” linkedin.com/in/maiconheck twitter.com/maicon_heck github.com/maiconheck medium.com/@maiconheck
- 3. Conteúdo ▪ OOP e a síndrome do “isso eu já sei” (o problema e a teoria) ▪ Estratégia para entender e colocar em prática os Design Patterns ▪ Exemplos de implementações de projetos reais
- 4. Programação orientada a objetos e a síndrome do "isso eu já sei"
- 5. Irônico: Se o dev afirma que já sabe OOP, porque temos tanto código ad-hoc? Mamífero Falar() Pessoa Cão Gato 1º. Sem conexão com software. 2º. Gera a falsa percepção de que é simples assim, logo não se estuda. Falar(); // MiauFalar(); // AoaoFalar(); // Olá Basta olhar Para o mundo Real! Sério?
- 6. Advertência do Gof 1º Parágrafo: Gamma, Helm, Johnson, Vlissides (1994)
- 7. Os catálogos
- 8. Categorias e características 1. Creational 2. Structural 3. Behavioral ● Intent ● Motivation ● Applicability ● Structure ● Participants ● Collaborations ● Consequences ● Implementation ● Related Patterns
- 9. Os mais frequentes 1. Factory Method 2. Abstract Factory 3. Singleton 4. Facade 5. Adapter 6. Decorator 7. Strategy 8. Command 9. Chain of Responsibility 1. Factory Method 2. Abstract Factory 3. Singleton 4. Facade 5. Adapter 6. Decorator 7. Strategy 8. Command 9. Chain of Responsibility B S C
- 10. Caso de Uso Conciliação Bancária 15 categorias de lançamento diferentes, onde 8 foram agrupadas em ProdutoNaoIdentificado = 7 rotinas Exemplo do mundo real
- 11. Strategy Receita de bolo: INDENTIFICAR -> ENTENDER -> APLICAR, se REPETE em todos Design Patterns Gamma, Helm, Johnson, Vlissides (1994)
- 12. Strategy Gamma, Helm, Johnson, Vlissides (1994)
- 13. Strategy (CreditoCobranca, PagamentoEletronico, ProdutoDespesa, ProdutoNaoIdentificado (8), ProdutoRendimento, ProdutoResgate, Tributo) Gamma, Helm, Johnson, Vlissides (1994)
- 14. “
- 15. Factory Method Factory Method + Abstract Factory? Gamma, Helm, Johnson, Vlissides (1994)
- 16. Factory Method Gamma, Helm, Johnson, Vlissides (1994)
- 17. Abstract Factory Exemplo do mundo real Gamma, Helm, Johnson, Vlissides (1994)
- 18. Abstract Factory Gamma, Helm, Johnson, Vlissides (1994)
- 19. Abstract Factory (ICommandResultFactory) (BasicCommandResultFactory, DefaultCommandResultFactory, ThirdPartyCommandResultFactory) (ICommandResult) (BasicCommandResult, DefaultCommandResult, ThirdPartyCommandResult) Gamma, Helm, Johnson, Vlissides (1994)
- 20. Abstract Factory Gamma, Helm, Johnson, Vlissides (1994)
- 21. “
Notas do Editor
- Todo mundo sabe que aplicar design patterns para resolver problemas reais melhora, significativamente a qualidade do código. Mas por algum motivo design patterns é uma espécie de tabú.
- Quando o tema da conversa é OOP o dev enche o peito pra dizer isso eu já sei, isso é básico, trivial.
- Será que são os prazos? Eu acho que muitos sabem apenas superficialmente. Conhecem os conceitos de herança, abstração, encapsulamento e polimorfismo. Agregação / Composição, Associação, Delegação. Mas não conseguem colocar na prática. Porque muitos aprenderam OOP com exemplos acadêmicos ruins: Herança (especialização / generalização): Tenho uma classe base mamífero, e pessoa, gato e cachorro herdam de mamífero trazendo dele seus atributos e operações em comum. E Polimorfismo é o método Falar(); que assume diversas formas. Encapsulamento: Eu não preciso entender do sistema de ignição, eu só preciso saber colocar a chave e girar. E por último vem o clássico: “Basta olhar para o mundo real” A comparação com o mundo real é ilusória. Essa analogia é uma abstração. Exemplo da modelagem do cálculo de imposto de renda no mundo real com OOP.
- O primeiro filtro que a gente deve aplicar para começar a desfazer essa confusão em torno dos DPs, é o filtro por catálogos. Porque? Porque são muitos DPs, só o GoF tem 23. Cada catálogo é formados por uma série de DPs para a solução de problemas em comum. [Citar os 3], o Gof para problemas de design OO, ... Existe inclusive esse catálogo “Analysis Patterns” onde o Martin Fowler reuniu uma série de DPs de análise de domínios comuns. Faz sentido porquê, por exemplo, existem N formas de modelar um módulo de contas a pagar, mas existe uma forma que já foi amplamente usada, testada e documentada e funciona muito bem, e o uso dela vai nos levar ao mesmo resultado confiável e elegante que outros que a utilizaram obtiveram. E esse é o objetivo dos design patterns. A qual catálogo nós vamos recorrer, depende do tipo de problema que nós precisamos resolver. E dentro de cada catálogo nós ainda precisamos escolher o design pattern específico para o problema em questão. E aqui a gente vai filtrar pelo Gof, e eu sugiro começar por ele, porque é fundamental. Foi o primeiro trabalho de DPs em software e é o alicerce fundamental, outros catálogos citam e constrõem em cima dele. Ex.: Aggregate.
- O segundo filtro é o de categorias e características. Que na prática significa: entender como funcionam e estão organizados. Nosso filtro por catálogo, reduziu o escopo para 23 DPs para resolver problemas de OO. Mas será que o problema que eu tenho agora, pode ser resolvido por algum deles, se sim, qual deles? Se DPs são formas de resolver problemas, aqui essas são as categorias de problemas que nós temos. Isso já deixa bem mais claro né? Mas do que eles são compostos? … Vejam que os DPs são receitas de bolo. [Intent… Implementation]
- [FAZER CONSIDERAÇÃO]: Essa lista é baseada na minha experiência e no senso comum. Portanto isso é relativo. Vai depender do domínio no qual vocês vão estar trabalhando. Por exemplo, se vocês estiverem modelando um editor gráfico composite se encaixa perfeitamente. Editor de texto o flyweight.
- 7 rotinas diferentes (fonte de dados, processamento e gravação)
- Todo esse passo a passo que eu estou fazendo é para demonstrar esse passo a passo de INDENTIFICAR -> ENTENDER -> APLICAR um desgin pattern. Porque esse processo se repete para todos eles
- Explicar como funcionam e a relação entre eles.