Como sabemos una constante en el desarrollo de software es el CAMBIO, el software que es bien diseñado es fácil hacer cambios.
La forma mas fácil de hacer que nuestro software sea fácil de cambiar es asegurarnos que Cada clase tiene solo una razón para cambiar. En otras palabras, estaremos reduciendo las posibilidades de que una clase tenga que cambiar reduciendo el número de responsabilidades que una clase tenga.
Veamos un ejemplo:
La clase Automovil tiene VARIAS responsabilidades que podrían causar que tenga que cambiar si un mecánico cambia la forma como checa el aceite, o si un conductor maneja el carro de forma diferente, o si el lavado de carros es actualizado, este código necesitaría cambiar.
Cuando observemos que una clase tiene mas de una razón para cambiar, es probable que tenga responsabilidades de más. Si descomponemos la funcionalidad en diferentes clases, donde cada clase tiene solo pocas responsabilidades y por lo tanto solo una razón para cambiar.
Ahora la clase Automovil es mucho mas simple y mucho mas flexible al cambio, las clases Conductor y LavadoDeCoches solo tienen una responsabilidad, así que las posibilidades de que cambien son mas reducidas.
Un termino muy relacionado con este principio es la Cohesión. La cohesión esta relacionada en medir cuanto una clase hace solo una cosa bien y no intenta tomar responsabilidades de más.
Un diseño con una medida de alta Cohesión es débilmente acoplada, entre mayor sea la medida de Cohesión, mas débilmente es el acoplamiento entre nuestras clases, por lo tanto siempre debemos de asegurarnos que nuestras clases sean cohesivas es decir, cada una de nuestras clases deben tomar solo una responsabilidad correctamente. Siempre debemos esforzarnos por mantener una alta Cohesión en el ciclo de vida de nuestros diseños.
No hay comentarios:
Publicar un comentario