SOLID a 6 mãos
•
10 gostaram•1,349 visualizações
O documento discute os princípios SOLID de design de software, que visam criar código flexível, reutilizável e fácil de manter. Os princípios abordados incluem responsabilidade única, aberto/fechado, substituição de Liskov, inversão de dependência e segregação de interface. Seguidos corretamente, esses princípios levam a código com menos cheiros e mais resistente a mudanças.
Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (20)
SOLID a 6 mãos
- 2. Sólido, mas não engessadoSólido, mas não engessado Código engessado apodrece e cheira mal.
- 3. Sólido, mas não engessadoSólido, mas não engessado Como evitar o apodrecimento do código?
- 4. Sólido, mas não engessadoSólido, mas não engessado Código S.O.L.I.D. facilita a manutenção mudanças não quebram o código é reutilizável e reaproveitável
- 5. Sólido, mas não engessadoSólido, mas não engessado E como meu código pode ser S.O.L.I.D.?
- 6. S.R.P. - Princípio da responsabilidade únicaS.R.P. - Princípio da responsabilidade única O primeiro passo, é compreender responsabilidade.
- 7. S.R.P. - Princípio da responsabilidade únicaS.R.P. - Princípio da responsabilidade única Responsabilidade única, por quê?
- 8. S.R.P. - Princípio da responsabilidade únicaS.R.P. - Princípio da responsabilidade única Okay, tenho apenas uma responsabilidade. E agora?
- 9. S.R.P. - Princípio da responsabilidade únicaS.R.P. - Princípio da responsabilidade única Seu código ainda fede; Muito!
- 10. O.C.P. - Princípio Aberto/FechadoO.C.P. - Princípio Aberto/Fechado Agora você é proibido de editar seu código.
- 11. O.C.P. - Princípio Aberto/FechadoO.C.P. - Princípio Aberto/Fechado Aberto e fechado?! Não é antagônico?
- 12. O.C.P. - Princípio Aberto/FechadoO.C.P. - Princípio Aberto/Fechado Aberto para extensão; Fechado para edição.
- 13. O.C.P. - Princípio Aberto/FechadoO.C.P. - Princípio Aberto/Fechado A implementação é irrelevante. Trabalhe com abstrações.
- 14. O.C.P. - Princípio Aberto/FechadoO.C.P. - Princípio Aberto/Fechado Herança pode ser uma solução para variar o comportamento.
- 15. O.C.P. - Princípio Aberto/FechadoO.C.P. - Princípio Aberto/Fechado Herança?! Eu sei trabalhar com herança!
- 16. O.C.P. - Princípio Aberto/FechadoO.C.P. - Princípio Aberto/Fechado class User extends Database {}
- 17. L.S.P. - Princípio da substituição de LiskovL.S.P. - Princípio da substituição de Liskov Herança é mais complexo do que você imagina!
- 18. L.S.P. - Princípio da substituição de LiskovL.S.P. - Princípio da substituição de Liskov Se q(x) é uma propriedade demonstrável dos objetos x de tipo T. Então q(y) deve ser verdadeiro para objetos y de tipo S onde S é um subtipo de T.
- 19. L.S.P. - Princípio da substituição de LiskovL.S.P. - Princípio da substituição de Liskov WTF?!
- 20. L.S.P. - Princípio da substituição de LiskovL.S.P. - Princípio da substituição de Liskov Se q(x) é uma propriedade demonstrável dos objetos x de tipo T. Então q(y) deve ser verdadeiro para objetos y de tipo S onde S é um subtipo de T.
- 21. L.S.P. - Princípio da substituição de LiskovL.S.P. - Princípio da substituição de Liskov E como uso isso?
- 22. L.S.P. - Princípio da substituição de LiskovL.S.P. - Princípio da substituição de Liskov Validação de input nunca deve ser mais forte na derivação, do que é na classe base.
- 23. L.S.P. - Princípio da substituição de LiskovL.S.P. - Princípio da substituição de Liskov Validação do output nunca deve ser mais fraco na derivação, do que é na classe base.
- 24. L.S.P. - Princípio da substituição de LiskovL.S.P. - Princípio da substituição de Liskov Se não posso editar o código, como utilizo uma classe derivada?
- 25. D.I.P. - Princípio da inversão das dependênciasD.I.P. - Princípio da inversão das dependências Trabalhando com abstrações e invertendo as dependências.
- 26. D.I.P. - Princípio da inversão das dependênciasD.I.P. - Princípio da inversão das dependências Mas o que é dependência?
- 27. D.I.P. - Princípio da inversão das dependênciasD.I.P. - Princípio da inversão das dependências Em vez de criar as instâncias dentro das classes, devemos passá-las como parâmetros na forma de abstrações.
- 28. D.I.P. - Princípio da inversão das dependênciasD.I.P. - Princípio da inversão das dependências Abstração é um conceito. Uma ideia.
- 29. D.I.P. - Princípio da inversão das dependênciasD.I.P. - Princípio da inversão das dependências Confie na interface das coisas e não espere conhecer os detalhes da implementação.
- 30. D.I.P. - Princípio da inversão das dependênciasD.I.P. - Princípio da inversão das dependências Então é só eu criar uma interface com todos os métodos possíveis?
- 31. D.I.P. - Princípio da inversão das dependênciasD.I.P. - Princípio da inversão das dependências Esqueceu das responsabilidades?
- 32. D.I.P. - Princípio da inversão das dependênciasD.I.P. - Princípio da inversão das dependências É esperado que seus objetos se comportem de todas as formas possíveis?
- 33. D.I.P. - Princípio da inversão das dependênciasD.I.P. - Princípio da inversão das dependências Então qual a responsabilidade do seu objeto?
- 34. I.S.P. - Princípio da segregação das interfacesI.S.P. - Princípio da segregação das interfaces Faça com que sua interface deixe os outros saberem dessa, e somente dessa, responsabilidade.
- 35. I.S.P. - Princípio da segregação das interfacesI.S.P. - Princípio da segregação das interfaces Quanto mais coesa for a interface, mais fácil será sua reutilização.
- 36. Problemas de um mau designProblemas de um mau design Rigidez Uma única mudança, implica na mudança de vários outros componentes.
- 37. Problemas de um mau designProblemas de um mau design Fragilidade Quando mudamos alguma coisa, partes inesperadas da aplicação quebram.
- 38. Problemas de um mau designProblemas de um mau design Imobilidade Fica difícil reutilizar o código, pois fica difícil extrair uma parte de um todo.
- 39. Problemas de um mau designProblemas de um mau design Há mais maus cheiros entre seus objetos, do que essa vã apresentação pode lhe mostrar.