Cohesión y acoplamiento

En la facultad cursé una asignatura llamada "Técnicas de Diseño". El equipo que llevaba la asignatura no era una gran autoridad en el tema del diseño de software, temática de la materia, y el responsable de la cátedra tenía muchos defectos, pero debo reconocer que era una persona sumamente convencida de sus ideas. Quizás más por amor propio que otra cosa. En cualquier caso, él estaba convencido de que la cohesión y el acoplamiento eran dos conceptos fundamentales en el diseño de soluciones informáticas. Y la verdad es que tiene toda la razón.

Voy a intentar definir cohesión y acoplamiento, desde el punto de vista informático. La cohesión es el grado de cercanía entre dos o más elementos. Podríamos decir que es un conjunto de características que los une y, por lo tanto, los agrupa bajo un mismo denominador, define su identidad. El acoplamiento, en cambio, mide el grado de dependencia entre dos o más elementos. Esto quiere decir que, según su dependencia, estarán más o menos acoplados. Mayor dependencia implica mayor acomplamiento.

El objetivo final del diseño de software (o soluciones informáticas) en materia de estos dos conceptos es: Reducir al máximo el acoplamiento entre componentes y aumentar la cohesión interna de cada componente.

¿Qué quiere decir reducir el acoplamiento? Básicamente, lo más importante es saber definir las responsabilidades de cada componente para garantizar que la dependencia sea funcional o arquitectónica, no de implementación. Un ejemplo simple de acoplamiento es cuando un componente accede directamente a un dato que pertenece a otro componente. ¿Qué ocurre en ese caso? Pues que el resultado del comportamiento del componente A dependerá del valor del componente B, por lo tanto, están acoplados. Cabe destacar que el acoplamiento no es malo, ojo. Simplemente hay que saber eliminar el acoplamiento que no sea funcional o arquitectónico. En el caso de acoplamiento funcional, está bien que un componente de cálculo de probabilidades dependa de un componente de cálculo matemático básico, ya que es evidente que para calcular probabilidades será necesario aplicar fórmulas matemátics y resolver operaciónes aritméticas. En el caso de acoplamiento arquitectónico, se puede ver un ejemplo en el esquema MVC (modelo-vista-controlador). La capa del modelo realizará cambios de acuerdo con los parámetros que recibe del controlador, por lo tanto hay cierta dependencia, pero sólo como separación de capas de una arquitectura claramente definida.

¿Qué ocurre en el caso de la cohesión? La cohesión de un componente mide la identidad de su comportamiento. El comportamiento de un componente se define mediante una serie de operaciones (contrato), cada una de ellas con una responsabilidad y función. La suma de todas las operaciones que definen dicho comportamiento integran una identidad. La cohesión no es buena cuando nos encontramos con que hay operaciones con un objetivo junto a otras con otro objetivo dentro de un mismo componente, cuya definición funcional es una y clara. Un ejemplo claro y sencillo de esto es el siguiente. Imaginemos un componente que gestiona el estado de una ficha de datos personales. Lo lógico sería que su contrato tuviese operaciones como "Actualizar nombres y apellidos", "Eliminar teléfono de contacto" y demás. Si defino una operación que calcula el pronóstico del tiempo en Tombuctú para el próximo fin de semana, pues la cohesión se anula completamente, ya que nada tiene que ver con el resto de operaciones y, sobretodo, con el fin del componente.

Con esto propongo un debate sobre estos dos conceptos, para enriquecernos entre todos y mejorar el uso que hacemos de ello a diario en nuestros diseños. Aunque no lo parezca, aplicamos estas ideas constantemente, en todos los niveles de un equipo de desarrollo de soluciones informáticas.

Un saludo para todos.

About these ads

22 comentarios to “Cohesión y acoplamiento”

  1. luis Says:

    deberias decir ademas que el acoplamiento y la cohesion son inversamente proporcionales. al tener bajo acomplamiento hay alta cohesion y viceversa.

  2. invitado Says:

    Pero tambien podria darse el caso de colocar todo en una misma clas, donde tendriamos cero cohesion y cero acoplamiento. ESta claro que esto es una muy mala practica, pero podria darse el caso.

  3. Alberto Rodríguez Says:

    Luís, hasta donde yo entiendo el acoplamiento y la cohesión no son inversamente proporcionales, sino que es una buena práctica tener bajo acoplamiento y alta cohesión.

    Aquí pongo un buen artículo sobre el tema:

    http://latecladeescape.com/w0/ingenieria-del-software/acoplamiento-y-cohesion.html

  4. javier Says:

    Excelente artículo.

  5. mho Says:

    gracias por el articulo!

  6. elo Says:

    Hola
    Gracias por el articulo, es muy claro, si no me equivoco la cohesion tiene que ver tambien con los nombres de tus variables y metodos, es decir el nombre tiene que “describir” la funcion de la variable u objeto, saludos
    lo ideal “alta cohesion bajo acoplamiento”

  7. Kalay Says:

    Muy bueno. La cohesion y el acoplamiento no veo porque son inversamente proporcionales. Yo puedo tener una clase que no dependa de ninguna (bajo acoplamiento) pero con muchas funciones diferentes y que no tienen nada que ver entre ellas (baja cohesión). O tambien al revés, una clase con funciones que sólo afecta a una tabla (alta cohesión), pero que coje los datos de muchas clases diferentes (alto acoplamiento). Al principio estas propiedades no parecen importantes, pero cuando has de hacer una modificación en el programa se nota la diferencia, ahora estoy modificando un programa con alto acoplamiento y es un infierno !

  8. Fede Says:

    Gracias! Si la clase tiene baja cohesión, entonces hay un fallo de diseño. Una clase con muchos métodos que nada tienen que ver uno con otros denota una mezcla de responsabilidades de la clase. Suena más a cajón de sastre que a una clase con un objetivo y una responsabilidad claras. La metodología CRC es muy buena en ese sentido, nos hace ver con claridad la necesidad de definir la misión de cada clase en nuestro sistema. Por otro lado, el alto acoplamiento, como bien dices, es un auténtico infierno a la hora de hacer modificaciones…

  9. Sele Says:

    Hola Fede,

    Gracias por tu artículo a mi tambien me parece muy claro, sin embargo me surge una duda con el acoplamiento, con los ejemplos de cohesion funcional y arquitéctonica me queda claro, pero puedes mencionar uno de implementación? un ejemplo claro porfavor

  10. Pilar Stronguilo Says:

    Muy clara tu explicación y muy buenos ejemplos. Gracias.

  11. 3dcondec Says:

    Muy buen blog, interesante tema, para los interesados en el diseño grafico 3D les recomiendo visitar mi blog http://www.3dcondec.wordpress.com
    Saludos Alex13

  12. jazmin Says:

    me encanta….. muxas graxcias

  13. Edgarin Says:

    Alguién q aclare la diferencia entre funcional y arquitectonico… para mi eso es PRACTICO de acuerdo al objetivo que se desea obtener….

    debíl acoplamiento claro para que cada componente sea lo mas indiviudal posible, para cogerlo y colocarlo como un foco dentro de una casa… y la cohesion.. bueno me parece que se refiere a que todos los tipos de focos deben estar en un mismo lugar… pero organizados para facilitar su búsqueda y asi saber cual hace falta en un determinado momento…

    ¿que creen ustedes?…

  14. Eric Says:

    Me ha parecido un artículo muy interesante, yo cursé la asignatura de ingeniería del Software pero nos la enseñaron en un momento demasiado temprano de la carrera… ahora que estoy en último año, veo la gran importancia de todos estos temas y estoy re-aprendiéndolos. Me ha sido de gran ayuda, gracias.

    Un saludo

  15. Mariano Says:

    Hola, una vez en un examen me preguntaron:
    La calidad de diseño se mide solamente a travez de la cohesion y el acoplamiento?
    Es falsa o verdadera?

  16. John Ortiz Says:

    Muchas gracias por esta entrada.

    Estoy muy interesado en mejorar mis habilidades en el desarrollo de sistemas buscando en varios medios, realizando cursos gratuitos, desde luego también lo que ofrece la Universidad.

    Me gustaría me pudieras enviar el contenido del curso de “Técnicas de Diseño” que seguiste.

    Estare atento a su respuesta.

    Me puede encontrar en Twitter como: @JohnOrtiO

    Hasta entonces.

  17. AA! Says:

    Excelente artículo. Muchas gracias.

  18. David Franco Says:

    Muy buen artículo. Saludos!

  19. Juan Gabriel Guzmán (@juanultimate_ec) Says:

    Excelente artículo. Me gusto el ejemplo de los focos.

  20. anonimo Says:

    muy buena explicación, gracias, me sirvió para responder una dada, mientras estudiaba para mi examen, son conceptos importantes al estudiar ingeniería de software basado en componentes

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s


Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

%d personas les gusta esto: