Este documento explica los principios SOLID de diseño orientado a objetos. Brevemente describe cada principio: el Principio de Responsabilidad Única, el Principio Abierto/Cerrado, el Principio de Sustitución de Liskov, el Principio de Segregación de Interfaz y el Principio de Inversión de Dependencias. El objetivo de estos principios es lograr software flexible, reutilizable y mantenible.

1. Principios SOLID de Programación Orientada a Objetos

2. ¿Diseño Orientado a Objetos? ¿Qué es? ¿De qué trata?

3. ¿Diseño Orientado a Objetos? Separación de responsabilidades. Encapsulamiento. Manejo de dependencias.

4. ¿Cómo hacemos software? ¿Qué va mal en esta historia?

5. ¿Cómo hacemos software? Empezamos…

6. ¿Cómo hacemos software? Se empieza a usar…

7. ¿Cómo hacemos software? Tienes que hacer cambios… SayWhat?

8. ¿Cómo hacemos software? Luego… nuevos cambios…

9. ¿Cómo hacemos software? Y más…. y más cambios…

10. ¿Cómo hacemos software? Encuentras solución…

11. ¿Cómo hacemos software? Este código se está pudriendo…

12. Aquí huele raro… ¿Cuándo sabes que comienza a podrirse? Rezas para que no tengas que hacer cambios. Cambios “sencillos” toman semanas… Trabajar con el código es una tortura… Etc.

13. Aquí huele raro… ¿Por qué? Rigidez: Tantas interdependencias que un cambio implica cambios por todas partes. Fragilidad: El sistema se rompe fácilmente, y en lugares que no relacionados.

14. Aquí huele raro… ¿Por qué? Movilidad: El código no es reusable. Viscosidad: En sus dos vertientes, diseño y entorno.

15. Aquí huele raro… ¿ok… pero… cómo sucede?

16. Aquí huele raro… ¡El código crece!

17. Aquí huele raro… Y si no se mantiene adecuadamente…

18. Aquí huele raro… Se hecha a perder…

19. Aquí huele raro…

20. Aquí huele raro…

21. Aquí huele raro…

22. Aquí huele raro…

23. Comparación ¿Cuáles son las diferencias? Primer ejemplo Las políticas de alto nivel dependen directamente de las de bajo nivel. Segundo ejemplo Las políticas de alto y bajo nivel dependen de abstracciones.

24. SOLID ¿Qué es eso?

25. SOLID ¿Qué es eso? Single ResponsibilityPrinciple Open ClosedPrinciple LiskovSubstitutionPrinciple Interface SegregationPrinciple DependencyInversionPrinciple

27. Single ResponsibilityPrinciple ¿Qué hace este código?

28. Single ResponsibilityPrinciple

29. Single ResponsibilityPrinciple “Una clase debería tener una, y solo una razón para cambiar” Robert C. Martin Principles of Object Oriented Design

30. Single ResponsibilityPrinciple

31. Single ResponsibilityPrinciple

32. Single ResponsibilityPrinciple ¿Que hay del encapsulamiento? ¿No debería de saber como se salva a si mismo? ¿?

33. SOLID ¿Qué es eso? Single ResponsibilityPrinciple Open ClosedPrinciple LiskovSubstitutionPrinciple Interface SegregationPrinciple DependencyInversionPrinciple

35. Open-ClosedPrinciple “Todo módulo debe estar abierto para la extensión pero, cerrado para modificación” Bertrand Meyer ObjectOriented Software Construction

36. Open-ClosedPrinciple ¿Qué quiere decir esto? Afectar el comportamiento, sin modificar.

37. Open-ClosedPrinciple Abierto para extensión: ¿Cómo podemos hacerlo comportarse en nuevas y distintas formas a medida que la aplicación evoluciona, o para ajustarse a las necesidades de nuevas aplicaciones?

38. Open-ClosedPrinciple Cerrado para modificación: No se puede modificar el código de lo que hay.

39. Open-ClosedPrinciple

40. Open-ClosedPrinciple ¿Qué podemos hacer para resolverlo? Abstracción.

41. Open-ClosedPrinciple

42. Open-ClosedPrinciple Ejemplo Shapes 01

43. Open-ClosedPrinciple Ejemplo Shapes 02

44. Open-ClosedPrinciple ¿Es posible cerrar una clase al 100%?

45. Open-ClosedPrinciple ¿Cómo resolver el problema si queremos pintar los círculos antes que los rectángulos?

46. Open-ClosedPrinciple ¿Y si el orden no depende del tipo de la figura?

47. Open-ClosedPrinciple ¿Consejos para evitar romper este principio? Heurísticas para hacer esto posible: Hacer las variables miembro privadas.

48. Open-ClosedPrinciple

49. Open-ClosedPrinciple ¿Consejos para evitar romper este principio? Heurísticas para hacer esto posible: Hacer las variables miembro privadas. No tener variables globales. Nunca.

50. Open-ClosedPrinciple

51. Open-ClosedPrinciple ¿Consejos para evitar romper este principio? Heurísticas para hacer esto posible: Hacer las variables miembro privadas. No tener variables globales. Nunca. Evitar usar RTTI.

52. Open-ClosedPrinciple

53. SOLID Herramientas bases para lograr mantenibilidad: Abstracción. Herencia. Polimorfismo.

54. SOLID Pero… ¿Qué reglas siguen? ¿Qué características tienen en común? ¿Qué problemas nos podemos encontrar?

55. SOLID ¿Qué es eso? Single ResponsibilityPrinciple Open ClosedPrinciple LiskovSubstitutionPrinciple Interface SegregationPrinciple DependencyInversionPrinciple

57. LiskovSubstitutionPrinciple “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)

58. LiskovSubstitutionPrinciple

59. LiskovSubstitutionPrinciple Traduciendo… “Las funciones que usan punteros o referencias a clases base, deben ser capaces de usar objetos de clases derivadas sin saberlo”

60. LiskovSubstitutionPrinciple

61. LiskovSubstitutionPrinciple [Otro ejemplo sutil de violación del LSP] [código LSP]

62. LiskovSubstitutionPrinciple [El problema real LSP] [código LSP]

63. LiskovSubstitutionPrinciple ¿Qué fue mal? El programador hizo suposiciones. Square no se comporta como Rectangle. La relación “es un” se refiere al compor-tamiento extrínseco, no intrínseco.

64. LiskovSubstitutionPrinciple ¿Qué fue mal? Para que el “Open ClosedPrinciple” se mantenga todas las clases derivadas deben adherirse al comportamiento que el cliente espera.

65. LiskovSubstitutionPrinciple Designbycontract ™ (diseño por contrato) Precondiciones Post condiciones Invariantes

66. LiskovSubstitutionPrinciple Designbycontract Derivando, solo se puede remplazar: Precondición: por una más débil. Post condición: por una más fuerte.

67. LiskovSubstitutionPrinciple

68. LiskovSubstitutionPrinciple El problema: Añadir PersistentSet que se puede leer y escribir de un stream, pero… Condiciones: Usar librería de tercero. Requiere que los objetos internos sean PersistentObject

69. LiskovSubstitutionPrinciple

70. LiskovSubstitutionPrinciple Solución problemática: Conoce el tipo. Falla con una excepción en tiempo de ejecución.

71. LiskovSubstitutionPrinciple

72. LiskovSubstitutionPrinciple Solución que no se adhiere a LSP: Es una convención. Es fácil de violar. No funciona del todo (el nuevo). Hay que revenderla. Es restrictiva.

73. LiskovSubstitutionPrinciple

74. LiskovSubstitutionPrinciple Solución usando LSP: Transparente Menos restrictiva Inherente a la estructura del código

75. LiskovSubstitutionPrinciple LSP es parte fundamental del Open ClosedPrinciple.

76. SOLID ¿Qué es eso? Single ResponsibilityPrinciple Open ClosedPrinciple LiskovSubstitutionPrinciple Interface SegregationPrinciple DependencyInversionPrinciple

78. DependencyInversionPrinciple 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.”

79. DependencyInversionPrinciple ¿Por qué “inversión”? Las formas mas tradicionales de diseño de software como el diseño y análisis estructurado, promueven la creación de estructuras donde los módulos de alto nivel dependen sobre módulos de bajo nivel.

80. DependencyInversionPrinciple

81. DependencyInversionPrinciple ¡Es absurdo! … ¿Pero… por qué? Lo que queremos es la reutilización de los módulos de alto nivel. Los módulos de bajo nivel ya sabemos re-utilizarlos.

82. DependencyInversionPrinciple El concepto de capas (Layering) “… toda arquitectura orientado a objetos que esté bien estructurada tiene capas claramente definidas, donde cada capa ofrece una serie de servicios coherentes mediante una serie de interfaces bien controladas y definidas.” Grady Booch ObjectSolution (1996)

83. DependencyInversionPrinciple Interpretación (?)

84. DependencyInversionPrinciple Análisis Implicaciones de estas dependencias directas: ¡Las dependencias son transitivas! Cambios en las capas inferiores son susceptibles a propagarse. Es difícil reutilizar las capas superiores.

85. DependencyInversionPrinciple Interpretación

86. DependencyInversionPrinciple Análisis Implicaciones de estas dependencias indirectas: Desacoplo. Aislamiento. Reusabilidad. Estabilidad.

87. DependencyInversionPrinciple

88. DependencyInversionPrinciple

89. DependencyInversionPrinciple

90. DependencyInversionPrinciple

91. DependencyInversionPrinciple Indispensable para implementación de frameworks. Resistente al cambio Abstracción y detalle están aislados uno del otro, por lo que aumenta la mantenibilidad.

92. SOLID ¿Qué es eso? Single ResponsibilityPrinciple Open ClosedPrinciple LiskovSubstitutionPrinciple Interface SegregationPrinciple DependencyInversionPrinciple

94. Interface SegregationPrinciple Sabemos cómo manejar la complejidad del código. Pero… A medida que el código crece…

95. Interface SegregationPrinciple Las interfaces también crecen…

96. Interface SegregationPrinciple Fat interfaces (Interfaces gordas) Les falta cohesión. Pueden separarse en grupos donde cada grupo sirve a un conjunto diferente de clientes.

97. Interface SegregationPrinciple

98. Interface SegregationPrinciple Fat interfaces (Interfaces gordas) Estas interfaces se necesitan. Pero… !No todas en una sola clase!

99. Interface SegregationPrinciple Fat interfaces (Interfaces gordas) ¿De donde salen?

100. Interface SegregationPrinciple

101. Interface SegregationPrinciple

102. Interface SegregationPrinciple Clientes separados implican interfaces separadas.

103. Interface SegregationPrinciple ¿Por qué? Los clientes ejercen fuerzas sobre las interfaces que emplean.

104. Interface SegregationPrinciple ¿Cuáles son?

105. Interface SegregationPrinciple

106. Interface SegregationPrinciple

107. Interface SegregationPrinciple Implicaciones de estos cambios.

108. Interface SegregationPrinciple “Los clientes no deben de ser forzados a depender de interfaces que no utilizan.” Robert C. Martin

109. Interface SegregationPrinciple ¿Qué hacemos entonces?

110. Interface SegregationPrinciple

111. Interface SegregationPrinciple

112. SOLID Por último… Son principios, no leyes. Hay que conocerlos y entenderlos para saber utilizarlos apropiadamente. Todos deberíamos de aplicarlos.

113. SOLID Por último… Es la única forma de disminuir el número de programadores que cometen suicidio.

114. SOLID ¿Donde aprender más? www.objectmentor.com www.google.com Patterns and AdvancedPrinciples of OOD (R.Martin) ObjectOriented Software Construction (B. Meyer) ObjectOrientedAnalysis and Design (G. Booch)