Principios SOLID de Programación Orientada a Objetos<br />
¿Diseño Orientado a Objetos?<br />¿Qué es? ¿De qué trata?<br />
¿Diseño Orientado a Objetos?<br />	Separación de responsabilidades.<br />Encapsulamiento.<br />	Manejo de dependencias.<br />
¿Cómo hacemos software?<br />¿Qué va mal en esta historia?<br />
¿Cómo hacemos software?<br />Empezamos…<br />
¿Cómo hacemos software?<br />Se empieza a usar…<br />
¿Cómo hacemos software?<br />Tienes que hacer cambios…<br />SayWhat?<br />
¿Cómo hacemos software?<br />Luego… nuevos cambios…<br />
¿Cómo hacemos software?<br />Y más…. y más cambios…<br />
¿Cómo hacemos software?<br />Encuentras solución…<br />
¿Cómo hacemos software?<br />Este código se está pudriendo…<br />
Aquí huele raro… <br />¿Cuándo sabes que comienza a podrirse?<br />	Rezas para que no tengas que hacer cambios.<br />	Camb...
Aquí huele raro…<br />¿Por qué?<br />	Rigidez: Tantas interdependencias que un cambio implica cambios por todas partes.<br...
Aquí huele raro…<br />¿Por qué?<br />Movilidad: El código no es reusable.<br />Viscosidad: En sus dos vertientes, diseño y...
Aquí huele raro…<br />¿ok… pero… cómo sucede?<br />
Aquí huele raro…<br />¡El código crece! <br />
Aquí huele raro…<br />Y si no se mantiene adecuadamente…<br />
Aquí huele raro…<br />Se hecha a perder…<br />
Aquí huele raro…<br />
Aquí huele raro…<br />
Aquí huele raro…<br />
Aquí huele raro…<br />
Comparación<br />¿Cuáles son las diferencias?<br />Primer ejemplo<br />	Las políticas de alto nivel dependen directamente ...
SOLID<br />¿Qué es eso?<br />
SOLID<br />¿Qué es eso?<br />Single ResponsibilityPrinciple<br />	Open ClosedPrinciple<br />LiskovSubstitutionPrinciple<br...
Single ResponsibilityPrinciple<br />¿Qué hace este código?<br />
Single ResponsibilityPrinciple<br />
Single ResponsibilityPrinciple<br />“Una clase debería tener una, y solo una <br />razón para cambiar”<br />Robert C. Mart...
Single ResponsibilityPrinciple<br />
Single ResponsibilityPrinciple<br />
Single ResponsibilityPrinciple<br />¿Que hay del encapsulamiento?<br />¿No debería de saber como se salva a si mismo?<br /...
SOLID<br />¿Qué es eso?<br />	Single ResponsibilityPrinciple<br />Open ClosedPrinciple<br />LiskovSubstitutionPrinciple<br...
Open-ClosedPrinciple<br />“Todo módulo debe estar abierto para la extensión pero, cerrado para modificación”<br />Bertrand...
Open-ClosedPrinciple<br />¿Qué quiere decir esto?<br />	Afectar el comportamiento, sin modificar.<br />
Open-ClosedPrinciple<br />Abierto para extensión:<br />¿Cómo podemos hacerlo comportarse en nuevas y distintas formas a me...
Open-ClosedPrinciple<br />Cerrado para modificación:<br />No se puede modificar el código de lo que hay.<br />
Open-ClosedPrinciple<br />
Open-ClosedPrinciple<br />¿Qué podemos hacer para resolverlo?<br />Abstracción.<br />
Open-ClosedPrinciple<br />
Open-ClosedPrinciple<br />Ejemplo Shapes 01<br />
Open-ClosedPrinciple<br />Ejemplo Shapes 02<br />
Open-ClosedPrinciple<br />¿Es posible cerrar una clase al 100%?<br />
Open-ClosedPrinciple<br />¿Cómo resolver el problema si queremos pintar los círculos antes que los rectángulos?<br />
Open-ClosedPrinciple<br />¿Y si el orden no depende del tipo de la figura?<br />
Open-ClosedPrinciple<br />¿Consejos para evitar romper este principio?<br />Heurísticas para hacer esto posible:<br />	Hac...
Open-ClosedPrinciple<br />
Open-ClosedPrinciple<br />¿Consejos para evitar romper este principio?<br />Heurísticas para hacer esto posible:<br />	Hac...
Open-ClosedPrinciple<br />
Open-ClosedPrinciple<br />¿Consejos para evitar romper este principio?<br />Heurísticas para hacer esto posible:<br />	Hac...
Open-ClosedPrinciple<br />
SOLID<br />	Herramientas bases para lograr mantenibilidad:<br />	Abstracción.<br />		Herencia.<br />		Polimorfismo.<br />
SOLID<br />	Pero… <br />		¿Qué reglas siguen?<br />	¿Qué características tienen en 	común?<br />		¿Qué problemas nos podem...
SOLID<br />¿Qué es eso?<br />	Single ResponsibilityPrinciple<br />	Open ClosedPrinciple<br />LiskovSubstitutionPrinciple<b...
LiskovSubstitutionPrinciple<br />“Si para todo objeto o1 de tipo S existe un objeto o2 de tipo T tal que para todo program...
LiskovSubstitutionPrinciple<br />
LiskovSubstitutionPrinciple<br />Traduciendo…<br />“Las funciones que usan punteros o referencias a clases base, deben ser...
LiskovSubstitutionPrinciple<br />
LiskovSubstitutionPrinciple<br />[Otro ejemplo sutil de violación del LSP]<br />[código LSP]<br />
LiskovSubstitutionPrinciple<br />[El problema real LSP]<br />[código LSP]<br />
LiskovSubstitutionPrinciple<br />¿Qué fue mal?<br />El programador hizo suposiciones.<br />Square no se comporta como Rect...
LiskovSubstitutionPrinciple<br />¿Qué fue mal?<br />Para que el “Open ClosedPrinciple” se mantenga todas las clases deriva...
LiskovSubstitutionPrinciple<br />Designbycontract ™<br />(diseño por contrato)<br />Precondiciones<br />Post condiciones<b...
LiskovSubstitutionPrinciple<br />Designbycontract<br />Derivando, solo se puede remplazar:<br />	Precondición: por una más...
LiskovSubstitutionPrinciple<br />
LiskovSubstitutionPrinciple<br />El problema:<br />	Añadir PersistentSet que se puede leer 	y escribir de un stream, pero…...
LiskovSubstitutionPrinciple<br />
LiskovSubstitutionPrinciple<br />	Solución problemática:<br />	Conoce el tipo.<br />	Falla con una excepción en tiempo 	de...
LiskovSubstitutionPrinciple<br />
LiskovSubstitutionPrinciple<br />	Solución que no se adhiere a LSP:<br />		Es una convención.<br />		Es fácil de violar.<b...
LiskovSubstitutionPrinciple<br />
LiskovSubstitutionPrinciple<br />	Solución usando LSP:<br />	Transparente<br />	Menos restrictiva<br />	Inherente a la est...
LiskovSubstitutionPrinciple<br />LSP es parte fundamental del Open ClosedPrinciple.<br />
SOLID<br />¿Qué es eso?<br />	Single ResponsibilityPrinciple<br />	Open ClosedPrinciple<br />LiskovSubstitutionPrinciple<b...
DependencyInversionPrinciple<br />	A) “Los módulos de alto nivel no deben de depender de módulos de bajo nivel. Ambos debe...
DependencyInversionPrinciple<br />	¿Por qué “inversión”?<br />	Las formas mas tradicionales de diseño de software como el ...
DependencyInversionPrinciple<br />
DependencyInversionPrinciple<br />¡Es absurdo! … ¿Pero… por qué?<br />Lo que queremos es la reutilización de los módulos d...
DependencyInversionPrinciple<br />El concepto de capas (Layering)<br />“… toda arquitectura orientado a objetos que esté b...
DependencyInversionPrinciple<br />Interpretación (?)<br />
DependencyInversionPrinciple<br />Análisis<br />	Implicaciones de estas dependencias directas:<br />	¡Las dependencias son...
DependencyInversionPrinciple<br />Interpretación<br />
DependencyInversionPrinciple<br />Análisis<br />	Implicaciones de estas dependencias indirectas:<br />	Desacoplo.<br />	Ai...
DependencyInversionPrinciple<br />
DependencyInversionPrinciple<br />
DependencyInversionPrinciple<br />
DependencyInversionPrinciple<br />
DependencyInversionPrinciple<br />	Indispensable para implementación de frameworks.<br />Resistente al cambio<br />Abstrac...
SOLID<br />¿Qué es eso?<br />	Single ResponsibilityPrinciple<br />	Open ClosedPrinciple<br />LiskovSubstitutionPrinciple<b...
Interface SegregationPrinciple<br />	Sabemos cómo manejar la complejidad del código. Pero…<br />	A medida que el código cr...
Interface SegregationPrinciple<br />Las interfaces también crecen…<br />
Interface SegregationPrinciple<br />Fat interfaces<br />(Interfaces gordas)<br />	Les falta cohesión.<br />	Pueden separar...
Interface SegregationPrinciple<br />
Interface SegregationPrinciple<br />Fat interfaces<br />(Interfaces gordas)<br />	Estas interfaces se necesitan.<br />	Per...
Interface SegregationPrinciple<br />Fat interfaces<br />(Interfaces gordas)<br />¿De donde salen? <br />
Interface SegregationPrinciple<br />
Interface SegregationPrinciple<br />
Interface SegregationPrinciple<br />	Clientes separados implican interfaces separadas.<br />
Interface SegregationPrinciple<br />¿Por qué?	<br />	Los clientes ejercen fuerzas sobre las interfaces que emplean.<br />
Interface SegregationPrinciple<br />¿Cuáles son?<br />
Interface SegregationPrinciple<br />
Interface SegregationPrinciple<br />
Interface SegregationPrinciple<br />Implicaciones de estos cambios.<br />
Interface SegregationPrinciple<br />“Los clientes no deben de ser forzados a depender de interfaces que no utilizan.”<br /...
Interface SegregationPrinciple<br />¿Qué hacemos entonces?<br />
Interface SegregationPrinciple<br />
Interface SegregationPrinciple<br />
SOLID<br />Por último…<br />	Son principios, no leyes. Hay que conocerlos y entenderlos para saber utilizarlos apropiadame...
SOLID<br />Por último…<br />Es la única forma de disminuir el número de programadores que cometen suicidio.<br />
SOLID<br />¿Donde aprender más?<br />www.objectmentor.com<br />www.google.com<br />Patterns and AdvancedPrinciples of OOD ...
Próxima SlideShare
Cargando en…5
×

Principios SOLID de Diseño Orientado a Objetos

5.217 visualizaciones

Publicado el

Principios SOLID de Diseño Orientado a Objetos

  1. 1. Principios SOLID de Programación Orientada a Objetos<br />
  2. 2. ¿Diseño Orientado a Objetos?<br />¿Qué es? ¿De qué trata?<br />
  3. 3. ¿Diseño Orientado a Objetos?<br /> Separación de responsabilidades.<br />Encapsulamiento.<br /> Manejo de dependencias.<br />
  4. 4. ¿Cómo hacemos software?<br />¿Qué va mal en esta historia?<br />
  5. 5. ¿Cómo hacemos software?<br />Empezamos…<br />
  6. 6. ¿Cómo hacemos software?<br />Se empieza a usar…<br />
  7. 7. ¿Cómo hacemos software?<br />Tienes que hacer cambios…<br />SayWhat?<br />
  8. 8. ¿Cómo hacemos software?<br />Luego… nuevos cambios…<br />
  9. 9. ¿Cómo hacemos software?<br />Y más…. y más cambios…<br />
  10. 10. ¿Cómo hacemos software?<br />Encuentras solución…<br />
  11. 11. ¿Cómo hacemos software?<br />Este código se está pudriendo…<br />
  12. 12. Aquí huele raro… <br />¿Cuándo sabes que comienza a podrirse?<br /> Rezas para que no tengas que hacer cambios.<br /> Cambios “sencillos” toman semanas…<br /> Trabajar con el código es una tortura…<br /> Etc.<br />
  13. 13. Aquí huele raro…<br />¿Por qué?<br /> Rigidez: Tantas interdependencias que un cambio implica cambios por todas partes.<br /> Fragilidad: El sistema se rompe fácilmente, y en lugares que no relacionados.<br />
  14. 14. Aquí huele raro…<br />¿Por qué?<br />Movilidad: El código no es reusable.<br />Viscosidad: En sus dos vertientes, diseño y entorno. <br />
  15. 15. Aquí huele raro…<br />¿ok… pero… cómo sucede?<br />
  16. 16. Aquí huele raro…<br />¡El código crece! <br />
  17. 17. Aquí huele raro…<br />Y si no se mantiene adecuadamente…<br />
  18. 18. Aquí huele raro…<br />Se hecha a perder…<br />
  19. 19. Aquí huele raro…<br />
  20. 20. Aquí huele raro…<br />
  21. 21. Aquí huele raro…<br />
  22. 22. Aquí huele raro…<br />
  23. 23. Comparación<br />¿Cuáles son las diferencias?<br />Primer ejemplo<br /> Las políticas de alto nivel dependen directamente de las de bajo nivel.<br />Segundo ejemplo<br /> Las políticas de alto y bajo nivel dependen de abstracciones.<br />
  24. 24. SOLID<br />¿Qué es eso?<br />
  25. 25. SOLID<br />¿Qué es eso?<br />Single ResponsibilityPrinciple<br /> Open ClosedPrinciple<br />LiskovSubstitutionPrinciple<br /> Interface SegregationPrinciple<br />DependencyInversionPrinciple<br />
  26. 26.
  27. 27. Single ResponsibilityPrinciple<br />¿Qué hace este código?<br />
  28. 28. Single ResponsibilityPrinciple<br />
  29. 29. Single ResponsibilityPrinciple<br />“Una clase debería tener una, y solo una <br />razón para cambiar”<br />Robert C. Martin<br />Principles of Object Oriented Design<br />
  30. 30. Single ResponsibilityPrinciple<br />
  31. 31. Single ResponsibilityPrinciple<br />
  32. 32. Single ResponsibilityPrinciple<br />¿Que hay del encapsulamiento?<br />¿No debería de saber como se salva a si mismo?<br />¿?<br />
  33. 33. SOLID<br />¿Qué es eso?<br /> Single ResponsibilityPrinciple<br />Open ClosedPrinciple<br />LiskovSubstitutionPrinciple<br /> Interface SegregationPrinciple<br />DependencyInversionPrinciple<br />
  34. 34.
  35. 35. Open-ClosedPrinciple<br />“Todo módulo debe estar abierto para la extensión pero, cerrado para modificación”<br />Bertrand Meyer<br />ObjectOriented Software Construction<br />
  36. 36. Open-ClosedPrinciple<br />¿Qué quiere decir esto?<br /> Afectar el comportamiento, sin modificar.<br />
  37. 37. Open-ClosedPrinciple<br />Abierto para extensión:<br />¿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?<br />
  38. 38. Open-ClosedPrinciple<br />Cerrado para modificación:<br />No se puede modificar el código de lo que hay.<br />
  39. 39. Open-ClosedPrinciple<br />
  40. 40. Open-ClosedPrinciple<br />¿Qué podemos hacer para resolverlo?<br />Abstracción.<br />
  41. 41. Open-ClosedPrinciple<br />
  42. 42. Open-ClosedPrinciple<br />Ejemplo Shapes 01<br />
  43. 43. Open-ClosedPrinciple<br />Ejemplo Shapes 02<br />
  44. 44. Open-ClosedPrinciple<br />¿Es posible cerrar una clase al 100%?<br />
  45. 45. Open-ClosedPrinciple<br />¿Cómo resolver el problema si queremos pintar los círculos antes que los rectángulos?<br />
  46. 46. Open-ClosedPrinciple<br />¿Y si el orden no depende del tipo de la figura?<br />
  47. 47. Open-ClosedPrinciple<br />¿Consejos para evitar romper este principio?<br />Heurísticas para hacer esto posible:<br /> Hacer las variables miembro privadas.<br />
  48. 48. Open-ClosedPrinciple<br />
  49. 49. Open-ClosedPrinciple<br />¿Consejos para evitar romper este principio?<br />Heurísticas para hacer esto posible:<br /> Hacer las variables miembro privadas.<br /> No tener variables globales. Nunca.<br />
  50. 50. Open-ClosedPrinciple<br />
  51. 51. Open-ClosedPrinciple<br />¿Consejos para evitar romper este principio?<br />Heurísticas para hacer esto posible:<br /> Hacer las variables miembro privadas.<br /> No tener variables globales. Nunca.<br /> Evitar usar RTTI.<br />
  52. 52. Open-ClosedPrinciple<br />
  53. 53. SOLID<br /> Herramientas bases para lograr mantenibilidad:<br /> Abstracción.<br /> Herencia.<br /> Polimorfismo.<br />
  54. 54. SOLID<br /> Pero… <br /> ¿Qué reglas siguen?<br /> ¿Qué características tienen en común?<br /> ¿Qué problemas nos podemos encontrar?<br />
  55. 55. SOLID<br />¿Qué es eso?<br /> Single ResponsibilityPrinciple<br /> Open ClosedPrinciple<br />LiskovSubstitutionPrinciple<br /> Interface SegregationPrinciple<br />DependencyInversionPrinciple<br />
  56. 56.
  57. 57. LiskovSubstitutionPrinciple<br />“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”<br />Barbara J. Liskov<br />Keynote – Data abstraction and hierarchy (1987)<br />
  58. 58. LiskovSubstitutionPrinciple<br />
  59. 59. LiskovSubstitutionPrinciple<br />Traduciendo…<br />“Las funciones que usan punteros o referencias a clases base, deben ser capaces de usar objetos de clases derivadas sin saberlo”<br />
  60. 60. LiskovSubstitutionPrinciple<br />
  61. 61. LiskovSubstitutionPrinciple<br />[Otro ejemplo sutil de violación del LSP]<br />[código LSP]<br />
  62. 62. LiskovSubstitutionPrinciple<br />[El problema real LSP]<br />[código LSP]<br />
  63. 63. LiskovSubstitutionPrinciple<br />¿Qué fue mal?<br />El programador hizo suposiciones.<br />Square no se comporta como Rectangle.<br /> La relación “es un” se refiere al compor-tamiento extrínseco, no intrínseco.<br />
  64. 64. LiskovSubstitutionPrinciple<br />¿Qué fue mal?<br />Para que el “Open ClosedPrinciple” se mantenga todas las clases derivadas deben adherirse al comportamiento que el cliente espera.<br />
  65. 65. LiskovSubstitutionPrinciple<br />Designbycontract ™<br />(diseño por contrato)<br />Precondiciones<br />Post condiciones<br />Invariantes<br />
  66. 66. LiskovSubstitutionPrinciple<br />Designbycontract<br />Derivando, solo se puede remplazar:<br /> Precondición: por una más débil.<br /> Post condición: por una más fuerte.<br />
  67. 67. LiskovSubstitutionPrinciple<br />
  68. 68. LiskovSubstitutionPrinciple<br />El problema:<br /> Añadir PersistentSet que se puede leer y escribir de un stream, pero…<br /> Condiciones:<br /> Usar librería de tercero.<br /> Requiere que los objetos internos sean PersistentObject<br />
  69. 69. LiskovSubstitutionPrinciple<br />
  70. 70. LiskovSubstitutionPrinciple<br /> Solución problemática:<br /> Conoce el tipo.<br /> Falla con una excepción en tiempo de ejecución.<br />
  71. 71. LiskovSubstitutionPrinciple<br />
  72. 72. LiskovSubstitutionPrinciple<br /> Solución que no se adhiere a LSP:<br /> Es una convención.<br /> Es fácil de violar.<br /> No funciona del todo (el nuevo). <br /> Hay que revenderla.<br /> Es restrictiva.<br />
  73. 73. LiskovSubstitutionPrinciple<br />
  74. 74. LiskovSubstitutionPrinciple<br /> Solución usando LSP:<br /> Transparente<br /> Menos restrictiva<br /> Inherente a la estructura del código<br />
  75. 75. LiskovSubstitutionPrinciple<br />LSP es parte fundamental del Open ClosedPrinciple.<br />
  76. 76. SOLID<br />¿Qué es eso?<br /> Single ResponsibilityPrinciple<br /> Open ClosedPrinciple<br />LiskovSubstitutionPrinciple<br /> Interface SegregationPrinciple<br />DependencyInversionPrinciple<br />
  77. 77.
  78. 78. DependencyInversionPrinciple<br /> A) “Los módulos de alto nivel no deben de depender de módulos de bajo nivel. Ambos deben depender de abstracciones.”<br />B) “Las abstracciones no deben depender de detalles. Los detalles deben depender de abstracciones.”<br />
  79. 79. DependencyInversionPrinciple<br /> ¿Por qué “inversión”?<br /> 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.<br />
  80. 80. DependencyInversionPrinciple<br />
  81. 81. DependencyInversionPrinciple<br />¡Es absurdo! … ¿Pero… por qué?<br />Lo que queremos es la reutilización de los módulos de alto nivel.<br /> Los módulos de bajo nivel ya sabemos re-utilizarlos.<br />
  82. 82. DependencyInversionPrinciple<br />El concepto de capas (Layering)<br />“… 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.”<br />Grady Booch<br />ObjectSolution (1996)<br />
  83. 83. DependencyInversionPrinciple<br />Interpretación (?)<br />
  84. 84. DependencyInversionPrinciple<br />Análisis<br /> Implicaciones de estas dependencias directas:<br /> ¡Las dependencias son transitivas!<br /> Cambios en las capas inferiores son susceptibles a propagarse.<br /> Es difícil reutilizar las capas superiores.<br />
  85. 85. DependencyInversionPrinciple<br />Interpretación<br />
  86. 86. DependencyInversionPrinciple<br />Análisis<br /> Implicaciones de estas dependencias indirectas:<br /> Desacoplo.<br /> Aislamiento.<br /> Reusabilidad.<br /> Estabilidad.<br />
  87. 87. DependencyInversionPrinciple<br />
  88. 88. DependencyInversionPrinciple<br />
  89. 89. DependencyInversionPrinciple<br />
  90. 90. DependencyInversionPrinciple<br />
  91. 91. DependencyInversionPrinciple<br /> Indispensable para implementación de frameworks.<br />Resistente al cambio<br />Abstracción y detalle están aislados uno del otro, por lo que aumenta la mantenibilidad.<br />
  92. 92. SOLID<br />¿Qué es eso?<br /> Single ResponsibilityPrinciple<br /> Open ClosedPrinciple<br />LiskovSubstitutionPrinciple<br />Interface SegregationPrinciple<br />DependencyInversionPrinciple<br />
  93. 93.
  94. 94. Interface SegregationPrinciple<br /> Sabemos cómo manejar la complejidad del código. Pero…<br /> A medida que el código crece…<br />
  95. 95. Interface SegregationPrinciple<br />Las interfaces también crecen…<br />
  96. 96. Interface SegregationPrinciple<br />Fat interfaces<br />(Interfaces gordas)<br /> Les falta cohesión.<br /> Pueden separarse en grupos donde cada grupo sirve a un conjunto diferente de clientes.<br />
  97. 97. Interface SegregationPrinciple<br />
  98. 98. Interface SegregationPrinciple<br />Fat interfaces<br />(Interfaces gordas)<br /> Estas interfaces se necesitan.<br /> Pero… !No todas en una sola clase!<br />
  99. 99. Interface SegregationPrinciple<br />Fat interfaces<br />(Interfaces gordas)<br />¿De donde salen? <br />
  100. 100. Interface SegregationPrinciple<br />
  101. 101. Interface SegregationPrinciple<br />
  102. 102. Interface SegregationPrinciple<br /> Clientes separados implican interfaces separadas.<br />
  103. 103. Interface SegregationPrinciple<br />¿Por qué? <br /> Los clientes ejercen fuerzas sobre las interfaces que emplean.<br />
  104. 104. Interface SegregationPrinciple<br />¿Cuáles son?<br />
  105. 105. Interface SegregationPrinciple<br />
  106. 106. Interface SegregationPrinciple<br />
  107. 107. Interface SegregationPrinciple<br />Implicaciones de estos cambios.<br />
  108. 108. Interface SegregationPrinciple<br />“Los clientes no deben de ser forzados a depender de interfaces que no utilizan.”<br />Robert C. Martin<br />
  109. 109. Interface SegregationPrinciple<br />¿Qué hacemos entonces?<br />
  110. 110. Interface SegregationPrinciple<br />
  111. 111. Interface SegregationPrinciple<br />
  112. 112. SOLID<br />Por último…<br /> Son principios, no leyes. Hay que conocerlos y entenderlos para saber utilizarlos apropiadamente. <br />Todos deberíamos de aplicarlos. <br />
  113. 113. SOLID<br />Por último…<br />Es la única forma de disminuir el número de programadores que cometen suicidio.<br />
  114. 114. SOLID<br />¿Donde aprender más?<br />www.objectmentor.com<br />www.google.com<br />Patterns and AdvancedPrinciples of OOD (R.Martin)<br />ObjectOriented Software Construction<br />(B. Meyer)<br />ObjectOrientedAnalysis and Design<br />(G. Booch)<br />

×