Académique Documents
Professionnel Documents
Culture Documents
(Carlos Fontela)
La idea de que un buen diseo debe estar basado en una alta cohesin y un bajo
acoplamiento viene de los aos 1980. Fue uno de los primeros principios proclamados del
diseo estructurado, y pas luego a la orientacin a objetos.
Y a qu llamamos cohesin y acoplamiento? Tiene que ver con la modularidad, as que
empecemos por ella.
Modularidad
El aporte ms importante que hizo el diseo estructurado fue la idea de que, para resolver
un problema complejo de desarrollo de software, conviene separarlo en partes ms
pequeas, que se puedan disear, desarrollar, probar y modificar, de manera sencilla y lo
ms
independientemente
posible
del
resto
de
la
aplicacin.
Por supuesto, la orientacin a objetos tambin tiene mdulos funcionales, que seran los
mtodos u operaciones de las clases, pero estos tienen una importancia menor respecto del
mdulo por excelencia, que es la clase.
Finalmente, en el diseo orientado a objetos, suele aparecer otro tipo de mdulo ms, el
paquete, de escasa relevancia semntica, pero importante para agrupar clases en el diseo
de aplicaciones medianas.
Cohesin
La cohesin tiene que ver con que cada mdulo del sistema se refiera a un nico proceso o
entidad. A mayor cohesin, mejor: el mdulo en cuestin ser ms sencillo de disear,
programar, probar y mantener.
En el diseo orientado a objetos las cosas son ms complejas. Como dijimos, hay tres tipos
de mdulos: clases, mtodos y paquetes. Con los mtodos, podemos adoptar las mismas
definiciones y recetas que para los procedimientos y funciones del diseo estructurado.
Qu ocurrira con los otros dos?
Las clases tendrn alta cohesin cuando se refieran a una nica entidad. Podemos
garantizar una fuerte cohesin disminuyendo al mnimo las responsabilidades de una clase:
si una clase tiene muchas responsabilidades probablemente haya que dividirla en dos o
ms. Y el test a aplicar sera ver si podemos describir a la clase con una oracin simple que
tenga un nico sustantivo en el sujeto. Si la clase estuviera representando alguna operacin
(por la aplicacin de algn patrn de diseo, por ejemplo), tambin habra que tratar de
sustantivarla y aplicarle la prueba para ver si es cohesiva. Una clase con alta cohesin
suele cumplir el principio de nica responsabilidad.
En los paquetes no es usual analizar cohesin. Sin embargo, nadie nos impide aplicarle los
mismos tests que a las clases. Sin embargo, lo crucial en los paquetes es el acoplamiento,
que vamos a ver ahora.
Acoplamiento
El acoplamiento mide el grado de relacionamiento de un mdulo con los dems. A menor
acoplamiento, mejor: el mdulo en cuestin ser ms sencillo de disear, programar,
probar y mantener.
De nuevo, el diseo orientado a objetos nos complica las cosas con sus tres tipos de
mdulos. A los mtodos, como pas con la cohesin, podemos analizarlos con los mismos
criterios que a los mdulos del diseo estructurado.
Una clase, en cambio, tendr bajo acoplamiento cuando tenga la menor dependencia
posible de otras clases. Esta dependencia significa que si bien puede haber muchas clases
que dependen de una debera haber pocas dependencias hacia otras clases desde una
sola. Las dependencias que importan son, de mayor a menor: generalizacin/herencia,
composicin, asociacin y dependencia dbil. Para visualizar estas cuestiones, los
diagramas de clases son herramientas fundamentales.
Y los paquetes? Un paquete debe cumplir con estos mismos requisitos, en el sentido de
que debe tener vinculaciones mnimas con otros paquetes. Decimos que hay dependencia
entre paquetes cuando hay clases de un paquete que dependen de clases de otro paquete,
sea por herencia, asociacin o simple dependencia dbil. En este caso, podemos ayudarnos
con un diagrama de paquetes, que debido a que nos muestra dependencias entre conjuntos
de clases, nos sirve para eliminar problemas de acoplamiento.