Principios de diseño SOLID
•Descargar como PPTX, PDF•
1 recomendación•234 vistas
Presentación sobre principios de diseño SOLID, hecha para el meetup de CaliJS.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Principios de diseño SOLID
Similar a Principios de diseño SOLID (20)
Último
Último (20)
Principios de diseño SOLID
- 1. Principios de diseño SOLID Manuel Zapata CaliJS – Octubre 2018
- 2. Hola, soy Manuel. Desarrollador y arquitecto de software. Co-organizador de Xamarin Cali. Blogger y YouTuber. Educador por pasión. Website: https://manuelzapata.co
- 5. Les presento al tío Bob
- 7. Un módulo debería tener una y solo una razón para cambiar
- 8. Veamos algo de código.
- 9. Principio de abierto cerrado Open Closed Principle (OCP)
- 10. Un módulo debería estar cerrado a modificaciones y abierto a extensiones
- 11. Veamos algo de código.
- 12. Principio de sustitución de Liskov Liskov Substitution Principle (LSP)
- 13. Hijo de tigre sale pintado
- 14. Debería ser posible sustituir una clase padre con una clase hija, sin que hayan comportamientos no deseados.
- 17. Los clientes no deberían depender de métodos que no utilicen.
- 18. UsuarioUno UsuarioDos UsuarioTres Principal + métodoUno + métodoDos + métodoTres
- 19. UsuarioUno UsuarioDos UsuarioTres PrincipalDos + métodoDos PrincipalUno + métodoUno PrincipalTres + métodoTres
- 20. Pero JavaScript no tiene interfaces
- 21. Pero Flow y TypeScript, sí.
- 22. No dependas de lo que no necesites.
- 23. Principio de inversión de dependencias Dependency Inversion Principle (DIP)
- 24. Los módulos de alto nivel no deberían depender de los módulos de bajo nivel. Primera idea
- 25. Las abstracciones no deberían depender de los detalles Segunda idea
- 27. Design smells • Rigidez. • Fragilidad. • Viscosidad. • Complejidad innecesaria. • Repetición innecesaria. • Opacidad. https://youtu.be/k9nvQemH9f4
- 28. https://manuelzapata.co/p rin Mini curso de principios de diseño
- 29. Si quieres aprender más de diseño y arquitectura de software… SoyManuelZapata @ManuelZapata ManuelZapata
- 30. Muchas gracias.
Notas del editor
- Módulo más malinterpretado. Un módulo debería tener una, y solo una, razón para cambiar. NO significa que debería hacer una sola cosa. Más difícil reusar. Dificultad de mantenimiento.
- Un artefacto software debería estar abierto para ser extendido, pero cerrado para ser modificado. Es un elemento crucial detrás de la arquitectura de muchos sistemas. El objetivo es hacer el sistema fácil de extender sin que los cambios sean de alto impacto. Esta extensión no solo se hace a través de herencia, sino que también se puede lograr mediante patrones de diseño.
- Va mucho más allá de la herencia. Existencia herencia no significa que el principio se cumpla. También aplica a otras cosas que no son herencia. Servicios REST mismas firmas de métodos.
- No necesariamente hablamos de interfaces. También hablamos de clases base, protocolos o incluso firmas de métodos.
- Por ejemplo, métodos con muchos parámetros.
- Deberían depender de abstracciones.
- Primer mal olor: rigidez La aplicación es difícil de cambiar, incluso para cosas muy pequeñas. El diseño es dificil de cambiar. Segundo mal olor: fragilidad La tendencia de un programa de dañarse en múltiples sitios, cuando un único cambio se hace. El diseño se daña muy fácil. Tercer mal olor: inmovilidad Es muy difícil separar el sistema en componentes que puedan ser reusados en otros sistemas. El diseño es difícil de reusar. Cuarto mal olor: viscosidad Los cambios que preservan el diseño son más difíciles de hacer que los machetes. Hacer las cosas mal es más fácil que hacer las cosas bien. Quinto olor: complejidad innecesaria El diseño es más complejo de lo necesario. Hay un exceso de diseño Sexto olor: repetición innecesaria Hay estructuras que se repiten. En mi último video hablé bastante sobre copiar y pegar. Séptimo olor: opacidad Código escrito de manera clara y expresiva VS Código escrito de manera extraña y confusa.