En el último artículo revisamos los principios de diseño de clases, como deben suponer, seguir tales principios por si solos no son suficientes para definir un diseño adecuado, es necesario definir la arquitectura de los paquetes, es decir como van a ser agrupadas las clases para evitar dependencias innecesarias o compilaciones extras debido a una mala organización.
PRINCIPIOS DE COHESION DE PAQUETES
REP :: Release/Reuse Equivalency Principle
La granularidad de reuso, determina la granularidad de release
Pongámoslo así, si la clase que modificamos, por diversas razones, obliga al usuario a hacer un upgrade cada vez que se le hace un release dicho usuario no considerará actualizar el software y es muy probable que abandone su uso.
Nosotros como desarrolladores, diseñadores o arquitectos debemos definir correctamente la agrupación de las clases, en este caso agrupándolas por el nivel de reuso que representa en paquetes con release conjunto. De esta forma liberamos código consistente ya que mantendremos existentes las versiones antiguas.
CCP :: Common Closure Principle
Clases que cambian juntas, deben agruparse juntas
Aquí es más conveniente indicar que la tarea de agrupar las clases, es una tarea de mucha paciencia y mucha concentración, ya que la forma en que agrupemos las clases incidirá en los releases que puedan ser necesarios por cada modificación, lo que repercutirá en la satisfacción del usuario
CRP :: Common Reuse Principle
Cambios a una clase que no nos interesa puede forzar al release de todo un paquete, por lo que
Las clases que no son usadas juntas, no deben juntarse en un paquete
Como podemos observar, estos principios son mutuamente exclusivos, sin embargo podemos utilizarlos de acuerdo a la etapa de desarrollo en la que nos encontremos; en la etapa inicial de desarrollo se puede establecer CCP como el principio a seguir, dando soporte a los entornos de desarrollo y pruebas; y se puede establecer REP y/o CRP para los usuarios finales a medida que el software se vuelva estable.
PRINCIPIOS DE UNION DE PAQUETES (COUPLING)
ADP :: ACYCLIC DEPENDENCY PRINCIPLE
La dependencia entre paquetes no debe ser circular
SDP :: Stable Dependency Principle
La dependencia debe ir en el sentido de la estabilidad
La estabilidad esta determinada por la cantidad de esfuerzo requerido para realizar un cambio, mientras más estable sea una clase más trabajo ha de requerir cualquier modificación; así para hacer que un paquete sea difícil de modificar las dependencias deben ir hacia el.
Les aconsejo a todos revisar el paper Design Principles and Design Patterns donde van a encontrar métricas para determinar la estabilidad de un paquete, así como el uso adecuado de ciertos patrones de diseño para mantener los principios que hemos revisado.
Dejen sus observaciones, tal vez podamos sacar nuevas ideas útiles.