Estructura
Introducció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  |