EstructuraIntroducción Objetivos Análisis de los principios Conclusiones
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
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
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
Principio de responsabilidad única
Una clase sólo puede tener una razón para cambiar Robert C. Martin
Diseño con una sola clase Cliente P Cliente Q Clase X Elementos asociados a la responsabilidad A Elementos asociados a la responsabilidad B
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
Diseño con dos clases Cliente P Cliente Q Clase X Elementos asociados a la responsabilidad A Elementos asociados a la responsabilidad B Cliente P Cliente Q Clase XA Elementos asociados a la responsabilidad A Clase XB Elementos asociados a la responsabilidad B Principio de responsabilidad única
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
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
Diseño con una clase
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 Cliente P Cliente Q Clase X Responsabilidad A Responsabilidad B
Diseño con dos clases Cliente P Cliente Q Clase XA Responsabilidad A Clase XB Responsabilidad B Principio de responsabilidad única
Análisis
Principio de separación de la interfaz
Los clientes no deben ser forzados a depender de interfaces que no utilizan Robert C. Martin
Diseño con una sola interfaz
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 Cliente C Cliente D Interfaz Z Métodos que utiliza el cliente C Métodos que utiliza el cliente D
| Página siguiente |