El documento presenta los principios SOLID de diseño de software. Introduce cada uno de los 5 principios: Responsabilidad Única, Abierto-Cerrado, Substitución de Liskov, Segregación de Interfaces e Inversión de Dependencia. Explica cada principio y sus implicancias para desarrollar software de calidad, flexible y mantenible. Finalmente, invita a las preguntas y comparte datos de contacto.

1. Disertante: Ing. Rocco, Sebastián
Mail: srocco@movizen.com
Web: ww.movizen.com
Blog: ww.srocco.com.ar
Jornada de Arquitectura de Software
Principios SOLID

2. Agenda
• ¿Qué diseño queremos?
• Síntomas de un mal diseño.
• Principios SOLID.
• Comentarios finales.
• Recursos adicionales.
• Preguntas.

3. ¿Qué diseño queremos?
• Cohesivo.
• Robusto.
• Flexible.
• Reusable.
• Mantenible.
• Testeable.

4. Síntomas de un mal diseño
• Rigidez.
• Fragilidad.
• Inmovilidad.
• Viscosidad.
• Complejidad innecesaria.
• Repetición innecesaria.
• Opacidad.

5. ¿Qué es SOLID?
• Acrónimo mnemónico.
• Introducido por Robert C. Martin a comienzos
de la década del 2000.
• Son cinco principios básicos de la
programación orientada a objetos y el diseño.
• Ayudan a desarrollar un software de
calidad, legible, entendible y fácilmente
testeable.

6. Principios SOLID
Single Responsibility Principle (SRP).
Open Closed Principle (OCP).
Liskov Substitution Principle (LSP).
Interface Segregation Principle (ISP).
Dependency Inversion Principle (DIP).

7. Principios SOLID
SRP: Principio de Responsabilidad Única.
OCP: Principio Abierto-Cerrado.
LSP: Principio de Substitución de Liskov.
ISP: Principio de Segregación de Interfaces.
DSI: Principio Inversión de Dependencia.

8. Responsabilidad única
“Una clase debería tener una, y solo una
razón para cambiar”
Robert C. Martin
Principles of Object Oriented Design

9. Responsabilidad única
• Clase con 2 o más responsabilidades:
– Responsabilidades acopladas.
• + responsabilidades, + probabilidades de cambio!
• Síntomas:
– Código spaghetti.
– "God Class“.
– Comentarios: “si”; “y”; ”pero”; “excepto”; “cuando”.
• Ventajas:
– Es más fácil re-utilizar partes del código.
– Las clases grandes son más difíciles de leer y cambiar.
– Solucionamos el dilema del nombre de la clase.

10. Responsabilidad única

11. Responsabilidad única

12. Abierto-Cerrado
“Todo módulo debe estar abierto para la
extensión pero, cerrado para modificación”
Bertrand Meyer
Object Oriented Software Construction

13. Abierto-Cerrado
• Los cambios deben generar código nuevo,
no modificar el código viejo.
• La clave está en la abstracción!
• Strategy and Template method son las formas
más comunes de satisfacer OCP.
• Ningún diseño se puede cerrar a TODOS los
cambios.

14. Abierto-Cerrado

15. Abierto-Cerrado

16. Substitución de Liskov
“Si para todo objeto o1 de tipo S existe un objeto
o2 de tipo T tal que para todo programa P
definido en función de T el comportamiento de
P no cambia cuando o1 es substituido por
o2, entonces S es un subtipo de T”
Barbara J. Liskov
Keynote – Data abstraction and hierarchy (1987)

17. Substitución de Liskov
Traduciendo…
“Las funciones que usan punteros o referencias
a clases base, deben ser capaces de usar
objetos de clases derivadas sin saberlo”
Robert C. Martin

18. Substitución de Liskov
• Es la base de poder del polimorfismo.
• Los subtipos deben ser substituibles por sus
tipos base.
• No podemos validar un modelo aisladamente.
– La validez depende del contexto (sus clientes).
• La violación de LSP es una violación latente de
OCP

19. Substitución de Liskov

20. Substitución de Liskov
• Un cuadrado puede ser un rectángulo….
– Pero el objeto cuadrado NO es un objeto rectángulo.
– El comportamiento no es igual!

21. Substitución de Liskov
• Diseñar basándose en comportamientos
• Pensar en “Sustituible por” y no en “Es un”-
• Diseño por contrato:
– Las pre-condiciones de los métodos de la sub-
clase no deben ser más fuertes que las de la clase
base.
– Las post-condiciones de los métodos de la sub-
clase no deben ser más débiles que las de la clase
base.

22. Substitución de Liskov

23. Substitución de Liskov

24. Segregación de Interfaces
“Los clientes no deben de ser forzados a
depender de interfaces que no utilizan.”
Robert C. Martin

25. Segregación de Interfaces
• Apunta a evitar las interfaces “gordas”.
• Les falta cohesión.
• No importa la cantidad de métodos, sino que
todos sus clientes las utilicen.
• Síntoma: “Unimplemented method”.
• Inadvertidamente podemos acoplar clientes
que usan ciertos métodos con otros clientes
que no los usan.

26. Segregación de Interfaces

27. Segregación de Interfaces

28. Inversión de dependencia
A) “Los módulos de alto nivel no deben de
depender de módulos de bajo nivel. Ambos
deben depender de abstracciones.”
B) “Las abstracciones no deben depender de
detalles. Los detalles deben depender de
abstracciones.”

29. Inversión de dependencia
• ¿ Por qué depender de una abstracción?
– El objeto cliente se desacopla de la
implementación.
– Podemos intercambiar la implementación (OCP!!)
• Problemas dependencias directas:
– ¡Las dependencias son transitivas!
• Ventajas dependencias indirectas:
– Desacoplamiento.
– Aislamiento.
– Reusabilidad.

30. Inversión de dependencia

31. Inversión de dependencia

32. SOLID - Comentarios Finales
• Definen lineamientos, no son reglas estrictas.
• Hay que comprender su motivación y aplicarlos
con criterio.
• No crear complejidad innecesaria!
• No es posible escribir código perfecto…
– TAMPOCO ES NECESARIO!
• No gastar recursos donde no es necesario.
• Con TDD, podemos refactorizar después!

33. SOLID - Comentarios Finales
“El elemento más volátil en los proyectos software
son los requisitos. Vivimos en un mundo de
requisitos cambiantes, y nuestro trabajo es estar
seguros de que nuestros software puede sobrevivir
a esos cambios, así que no culpes a los requisitos
cambiantes por los fallos en el software.”
Robert C. Martin

34. Recursos adicionales.

35. ¿Preguntas?

36. Muchas Gracias!

37. Datos de Contacto
Disertante: Ing. Rocco, Sebastián
Mail: srocco@movizen.com
Web: ww.movizen.com
Blog: www.srocco.com.ar