Programando_melhor_com_SOLID_-_TDC_2020.pdf

O termo SOLID é um acrônimo para cinco princípios de design de projetos orientados a objetos. Esses princípios foram criados para facilitar o entendimento, desenvolvimento e manutenção de softwares. A teoria por trás desses princípios foi apresentada por Robert C. Martin no artigo "Design Principles and Design Patterns", publicado no ano de 2000. Mais tarde, o acrônimo SOLID foi cunhado por Michael Feathers, que se baseou nas ideias apresentadas por Martin anteriormente. A vantagem de seguir os princípios SOLID é que eles proporcionarão um código mais fácil de se entender, manter, estender e com menor acoplamento. Assim, dominar esses princípios torna-se uma habilidade fundamental.

Transcript

1. Programando melhor com SOLID
2. Quem sou eu? github.com/gillianomenezes @gillianomenezes @gillianomenezes linkedin.com/in/gillianomenezes/ gillianomenezes@gmail.com Engenheiro de Software na Loadsmart
3. Sumário Introdução 4 Princípio da Responsabilidade Única 6 Princípio Aberto-Fechado 10 Princípio da Substituição de Liskov 16 Princípio da Segregação da Interface 23 Princípio da inversão da dependência 39 Conclusão 34
4. Introdução Em março de 1995, Robert C. Martin (Uncle Bob), escreveu um artigo sobre um conjunto de princípios para o design de projetos orientados a objetos que chegou a ser a base para o S.O.L.I.D.: SRP Princípio da Responsabilidade Única Uma classe deve ter um e apenas um motivo para mudar. OCP Princípio Aberto-Fechado Você deve poder estender um comportamento de classe, sem modificá-la. LSP Princípio da Substituição de Liskov Classes derivadas devem ser substituíveis por suas classes base. ISP Princípio da Segregação da Interface Muitas interfaces específicas são melhores do que uma interface única. DIP Princípio da inversão da dependência Dependa de uma abstração e não de uma implementação.
5. Motivação Os princípios SOLID devem ser aplicados para se obter os benefícios da orientação a objetos, tais como: • Seja fácil de se manter, adaptar e se ajustar às alterações de escopo; • Seja testável e de fácil entendimento; • Seja extensível para alterações com o menor esforço necessário; • Que forneça o máximo de reaproveitamento; • Que permaneça o máximo de tempo possível em utilização.
6. 1. Princípio da Responsabilidade Única (SRP) Uma classe deveria ter uma, e somente uma, razão para mudar.
7. 1. Princípio da Responsabilidade Única (SRP) Eu sou um chef, um jardineiro, um pintor e motorista Sou um chef Sou um jardin eiro Sou um jardineiro Sou um chef Sou um pintor Sou um motorista Sou um chef, um jardineiro, um pintor e um motorista Única responsabilidade
8. 1. Princípio da Responsabilidade Única (SRP) A classe de exemplo “Customer” viola o Princípio da Responsabilidade Única. Como?
9. 1. Princípio da Responsabilidade Única (SRP) Solução: Crie uma nova classe para lidar apenas com a persistência Crie uma nova classe para lidar apenas com a lógica de negócios
10. 2. Princípio Aberto-Fechado (OCP) Você deve poder estender um comportamento de classe, sem modificá-la.
11. 2. Princípio Aberto-Fechado (OCP) Eu posso cortar Eu posso cortar Agora eu posso pintar Agora eu posso pintar e cortar Aberto e fechado
12. 2. Princípio Aberto-Fechado (OCP) Exemplo: Gerar visualizações em HTML para objetos
13. 2. Princípio Aberto-Fechado (OCP) Como estendê-lo para que gere visualizações personalizadas?
14. 2. Princípio Aberto-Fechado (OCP)
15. 2. Princípio Aberto-Fechado (OCP) Solução:
16. 3. Princípio da Substituição de Liskov (LSP) Classes derivadas devem ser substituíveis por suas classes base.
17. 3. Princípio da Substituição de Liskov (LSP) Olá, sou o João. Eu faço café. Olá, sou a Maria. Sou filha do João. João, você poderia me fazer um café? Aqui está seu café Obrigado! Maria, João não está aqui no momento. Você poderia me fazer um café? Nao sei fazer café, mas aqui está uma água Maria, João não está aqui no momento. você poderia me fazer um café? Claro! Aqui está um cappuccino Obrigado! Substituição de Liskov
18. 3. Princípio da Substituição de Liskov (LSP) Exemplo:
19. 3. Princípio da Substituição de Liskov (LSP) Tarefa: Criar uma subclasse de BaseAccount que seja uma representação de uma conta corrente
20. 3. Princípio da Substituição de Liskov (LSP) Parece tudo certo, mas...
21. 3. Princípio da Substituição de Liskov (LSP) Solução:
22. 3. Princípio da Substituição de Liskov (LSP) Solução:
23. 4. Princípio da Segregação da Interface (ISP) Muitas interfaces específicas são melhores do que uma interface única.
24. 4. Princípio da Segregação da Interface (ISP) Ops! Eu não tenho antenas! Legal! Segregação de interface
25. 4. Princípio da Segregação da Interface (ISP) Exemplo: Um parser de eventos a partir de diversas fontes de dados, em diferentes formatos (XML, JSON, YAML, …)
26. 4. Princípio da Segregação da Interface (ISP) Pergunta: Mas o que acontece se uma classe específica precisar apenas do método XML?
27. 4. Princípio da Segregação da Interface (ISP) É melhor ter interfaces tão pequenas quanto possível...
28. 4. Princípio da Segregação da Interface (ISP) A classe que deseja usar o analisador XML implementará apenas o método parse_XML e nada mais :)
29. 5. Princípio da inversão da dependência (DIP) Dependa de uma abstração e não de uma implementação.
30. 5. Princípio da inversão da dependência (DIP) Inversão de dependência Eu corto pizza com meu braço cortador de pizza Eu corto pizza com a ferramenta que você me der
31. 5. Princípio da inversão da dependência (DIP) Exemplo: Serviço de de conexão HTTP
32. 5. Princípio da inversão da dependência (DIP) Solução:
33. 5. Princípio da inversão da dependência (DIP) Solução:
34. Conclusão Os princípios S.O.L.I.D. nos ajudam a ter um bom design de programação OO. Proporcionam um código menos rígido e frágil sendo mais fácil de manter e estender. Lembrem-se desses princípios ao escrever novos códigos. Refatore para aderir ao princípios S.O.L.I.D.
35. Para saber mais The Principles of OOD | Uncle Bob Princípios SOLID - Podcast 126 | Lambda3 SOLID(O básico para você programar melhor) | Código Fonte TV Orientação a Objetos e SOLID para Ninjas | Mauricio Aniche
36. Dúvidas?
37. Obrigado! ❤ github.com/gillianomenezes @gillianomenezes @gillianomenezes linkedin.com/in/gillianomenezes/ gillianomenezes@gmail.com