Almudena Moya Muñoz

1. Una vuelta de tuercaa los principios de diseño ágiles Almudena Moya Muñoz Julio 2006

2. Estructura • Introducción • Objetivos • Análisis de los principios • Conclusiones

3. Introducción • El problema de los cambios en el software • Gran diversidad de soluciones • Se necesita un instrumento teórico de ayuda al diseño de software • El instrumento podría ser la ambigüedad

4. Objetivos • Comprobar la validez de la ambigüedad como instrumento teórico para el análisis de los principios de diseño ágiles • Explicar y predecir el efecto de los principios • Ofrecer una visión unificada de los principios y un criterio para clasificarlos • Resolver varios aspectos confusos

5. Principios de diseño ágiles • Principio de responsabilidad única • Principio de separación de la interfaz • Principio abierto/cerrado • Principio de sustitución de Liskov • Principio de inversión de dependencias “Agile Software Development: Principles, Patterns, and Practices” Robert C. Martin

6. Principio de responsabilidad única Una clase sólo puede tener una razón para cambiar Robert C. Martin • Finalidad • Evitar que el cambio de una responsabilidad en una clase pueda provocar fallos en las demás responsabilidades de la clase • Evitar que los clientes de una clase carguen con elementos que no utilizan Diseño con una sola clase Clase X Cliente P Elementos asociados a la responsabilidad A Cliente Q Elementos asociados a la responsabilidad B

7. Principio de responsabilidad única Diseño con una sola clase Diseño con dos clases Clase XA Clase X Cliente P Elementos asociados a la responsabilidad A Cliente P Elementos asociados a la responsabilidad A Clase XB Cliente Q Elementos asociados a la responsabilidad B Cliente Q Elementos asociados a la responsabilidad B

8. Principio de responsabilidad única Justificación del principio según R. Martin Principio de cohesión (DeMarco y Pages-Jones) Cohesión: Relación funcional de los elementos de un modulo Cohesión = responsabilidad única (Martin) Principio de responsabilidad única (Martin) Responsabilidad: razón de cambio Cohesión: Fuerzas que provocan cambios en una clase o módulo

9. Principio de responsabilidad única ¿ cohesión = razón de cambio ? • Creencia • Alta cohesión y bajo acoplamiento conlleva facilidad de modificación • Problema (incluye lo que estaba escrito antes) • Infinitud de definiciones de cohesión y acoplamiento • Consecuencia • No hay justificación para asociar cohesión con fuerzas de cambio

10. Principio de responsabilidad única Análisis • Realidad del principio: • División salomónica puntual • Ambigüedad: • Aumenta entre los elementos de responsabilidades separadas • Aumenta entre la clase cliente hacia las clases separadas que no utilizan • Disminuye entre la clase cliente hacia las clases separadas que utilizan • Ventajas e inconvenientes Diseño con una clase Clase X Cliente P Responsabilidad A Cliente Q Responsabilidad B Diseño con dos clases Clase XA Cliente P Responsabilidad A Clase XB Cliente Q Responsabilidad B

11. Principio de separación de la interfaz Los clientes no deben ser forzados a depender de interfaces que no utilizan Robert C. Martin • Finalidad • Reducir las dependencias entre clientes que utilizan métodos diferentes de la misma interfaz • Evitar que los clientes de una clase carguen con elementos que no utilizan Diseño con una sola interfaz Interfaz Z Cliente C Métodos que utiliza el cliente C Cliente D Métodos que utiliza el cliente D

12. Principio de separación de la interfaz Diseño con una interfaz Diseño con dos interfaces interfaz ZC Interfaz Z Cliente C Métodos que utiliza el cliente C Cliente C Métodos que utiliza el cliente C Interfaz ZD Cliente D Métodos que utiliza el cliente D Cliente D Métodos que utiliza el cliente D

13. Principio de separación de la interfaz Análisis • Extensión del principio de responsabilidad única • Ambigüedad • Aumenta entre los métodos de interfaces separadas • Aumenta entre la clase cliente hacia los métodos de las interfaces no utilizan • Ventajas e inconvenientes Diseño con una interfaz Interfaz Z Cliente C Métodos cliente C Cliente D Métodos cliente D Diseño con dos interfaces Interfaz ZC Cliente C Métodos cliente C Interfaz ZD Cliente D Métodos cliente D

14. Principio abierto/cerrado Las entidades software deben estar abiertas para su extensión, pero cerradas para su modificación Bertran Meyer • Finalidad • Sistema funcionando (cerrado), pero ampliable (abierto) • Conseguir cambios añadiendo nuevo código sin afectar al resto de elementos del diseño Diseño cerrado/cerrado Clase A Clase B

15. Principio abierto/cerrado Análisis • Ambigüedad • La dependencia “uno a uno” se transforma en una dependencia de “uno a muchos” • Ventajas Diseño cerrado/cerrado Clase A Clase B Diseño abierto/cerrado Clase A Clase Abstracta B Clase B1 Clase B2

16. Principio de sustitución de Liskov Los subtipos deben ser sustituibles por sus supertipos Robert C. Martin S es subtipo de T (Barbara Liskov) o2 es un objeto de T o1 es un objeto de S Para todo programa P ( T ) comportamiento P(o1) = comportamiento P(o2) cuando o1 es sustituido por o2 • Finalidad • Facilitar la modificación del diseño y la reutilización del código a través del uso adecuado de la herencia Te cambié el orden de o1 y o2, pero no estoy seguro T S

17. Principio de sustitución de Liskov ¿ Rectángulo ES-UN Cuadrado ? Rectángulo ES – UN ? Cuadrado Propiedades y métodos Poscondiciones de los métodos establecerAlto y establecerAncho

18. Principio de sustitución de Liskov Análisis • Ambigüedad: • Los programas no saben si trabajan con objetos de supertipos o de subtipos • Ventajas • El enunciado de Martin es confuso: • “Los subtipos deben ser sustituibles por los supertipos”, pero la definición de subtipo se basa en la sustitución S es subtipo de T o1 es un objeto de S o2 es un objeto de T Para todo programa P ( T ) comportamiento P(o1) = comportamiento P(o2) cuando o1 es sustituido por o2 T S

19. Principio de inversión de dependencias Los módulos de alto nivel no deben depender de los módulos de bajo nivel. Ambos deben depender de las abstracciones Las abstracciones no deben depender de los detalles. Los detalles deben depender de las abstracciones. Robert C. Martin

20. Finalidad: Conseguir que los cambios en los módulos de bajo nivel no afecten a los módulos de alto nivel Facilitar la reutilización de los módulos de alto nivel Principio de inversión de dependencias Diseño tradicional Nivel Política Nivel Mecanismo Nivel Utilidad

21. Principio de inversión de dependencias Diseño tradicional Diseño con inversión de dependencias Política Nivel Política Interfaz Política Nivel Política Mecanismo Nivel Mecanismo Nivel Mecanismo Interfaz Mecanismo Nivel Utilidad Utilidad Nivel Utilidad

22. Principio de inversión de dependencias Análisis • Ambigüedad: • Aumenta entre los módulos de alto nivel y los de bajo nivel • Ventajas • Caso particular de la programación estructurada de Dijkstra Diseño con inversión de dependencias Política Nivel Política Interfaz Política Mecanismo Nivel Mecanismo Interfaz Mecanismo Utilidad Nivel Utilidad

23. Conclusiones (I) La ambigüedad ha sido un instrumento teórico válido para analizar los principios de diseño ágiles porque ha permitido: • Explicar y predecir los efectos de la aplicación de estos principios • Disponer de una visión uniforme de los principios

24. Conclusiones (II) Los principios: • abierto/cerrado • de sustitución • de inversión de dependencias aumentan la ambigüedad del diseño: • Reemplazo de las relaciones unívocas por ambiguas • Reducción la complejidad descriptiva • Reducción la complejidad por incertidumbre Son criterios de diseño para utilizarlos de forma regular

25. Conclusiones (III) Los principios: • de responsabilidad única • de separación de la interfaz diminuyen la ambigüedad del diseño: • Aumento de la complejidad descriptiva • Aumento de la complejidad por incertidumbre Son criterios de diseño para utilizarlos de forma excepcional

26. Conclusiones (y IV) Objeciones al trabajo de Martin: • No existe un análisis teórico de los principios • No hay relación entre el principio de cohesión y el principio de responsabilidad única • Enunciado tautológico del principio de sustitución • Principio de inversión de dependencias es un caso particular de la programación estructurada original (Dijkstra)