SOLID - Clean Architecture
Transferir como PPTX, PDF3 gostaram526 visualizações
O documento explica os princípios SOLID da programação orientada a objetos, definidos por Robert C. Martin. Os cinco princípios visam promover a manutenção de código limpo, coeso e de fácil entendimento, garantindo que cada classe tenha uma única responsabilidade. A adesão a esses princípios ajuda no desenvolvimento de sistemas que são abertos para extensão e fechados para modificação.
SOLID - Clean Architecture
- 1. E o solid?
- 2. Hello!Evelise Vazquez - Desenvolvedora Front-end na equipe Labs Eu vim de Santos, fã de Charlie Brown e péssima jogadora de DOOM nas horas vagas Medium e Twitter - @EveliseVazquez 2
- 3. SOLID é um acrônimo criado por Michael Feathers que representa os 5 princípios da programação orientada a objetos identificados por Robert Cecil Martin ou Uncle Bob nos princípios de 2000. 3
- 5. × A classe deve ter somente um motivo para ser modificada. × Cada responsabilidade deve ser uma classe e cada classe deve ter uma única responsabilidade. 5
- 6. 6 Classe com muitas responsabilidades: × Validar dados do cliente × Gerar Imposto × Salvar cupom fiscal × Imprimir cupom fiscal × Enviar cupom por email
- 7. 5 responsabilidades => 5 motivos para ser modificada. 7
- 8. × A falsa impressão de que o sistema está sendo construído de forma prática e simples, por conter poucas classes para manutenção. × A medida que o sistema cresce, a dificuldade aumenta. 8
- 9. 9
- 10. 10
- 11. × Facilidade de manutenção × Código limpo e de fácil entendimento × Redução do acoplamento (dependências) × Complexidade reduzida × Coesão das classes 11
- 13. Você deve ser capaz de estender um comportamento de uma classe sem a necessidade de modificá-lo 13
- 14. × Abertas para extensão, fechadas para modificação × Modificação através de: herança, interface ou composição 14
- 15. 15
- 16. 16
- 17. A ideia é criarmos novas classes para funcionalidades de tipos semelhantes 17
- 20. As classes derivadas devem ser substituíveis por suas classes bases 20
- 21. 21
- 22. 22 Não faz sentido essa extensão
- 23. 23
- 25. Classes não devem ser forçadas a depender de interfaces que elas não usam. 25
- 26. 26
- 27. 27
- 28. Interfaces que têm muitos comportamentos , além de quebrar o primeiro princípio de Single Responsability, dificulta a manutenção do código 28
- 29. 29
- 30. × Separando cada interface com a sua responsabilidade única. × Caso eu precise adicionar uma nova funcionalidade no celular, eu vou alterar apenas uma classe. 30
- 32. Dependa de abstrações e não de implementações. 32
- 33. × Depender de abstrações facilita a mudança por conter menos alterações do que uma classe. 33
- 34. 34
- 35. 35 Eu ODEIO mexer no seu código Você não segue o SOLID
- 36. 36
- 37. × A ideia de usar o SOLID é ideal para manter uma arquitetura de código legível e de fácil manutenção × Por ser um padrão, qualquer pessoa que entra em contato com o projeto consegue caminhar sozinha 37