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.
noviembre 26, 2007 a las 11:17 am |
deberias decir ademas que el acoplamiento y la cohesion son inversamente proporcionales. al tener bajo acomplamiento hay alta cohesion y viceversa.
marzo 18, 2008 a las 3:20 pm |
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.
septiembre 17, 2008 a las 5:40 pm |
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
diciembre 23, 2008 a las 1:39 pm |
Excelente artículo.
marzo 8, 2009 a las 10:17 pm |
gracias por el articulo!
May 4, 2009 a las 6:52 am |
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»
noviembre 9, 2010 a las 4:51 am |
No pelotudo, eso es declaratividad!.
junio 26, 2009 a las 10:52 am |
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 !
junio 26, 2009 a las 12:49 pm |
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…
octubre 1, 2009 a las 7:06 am |
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
abril 17, 2010 a las 1:13 pm |
Muy clara tu explicación y muy buenos ejemplos. Gracias.
octubre 12, 2010 a las 10:48 pm |
a mi me gusta tu trasero profe stronguilo…
junio 4, 2010 a las 5:41 am |
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
agosto 12, 2010 a las 10:02 pm |
me encanta….. muxas graxcias
octubre 30, 2010 a las 1:20 am |
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?…
diciembre 27, 2010 a las 1:34 am |
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
febrero 3, 2012 a las 9:09 pm |
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?
junio 10, 2012 a las 7:58 pm |
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.
julio 10, 2012 a las 8:41 pm |
Excelente artículo. Muchas gracias.
noviembre 17, 2012 a las 4:29 pm |
Muy buen artículo. Saludos!
diciembre 11, 2012 a las 10:08 pm |
Excelente artículo. Me gusto el ejemplo de los focos.
junio 30, 2013 a las 10:05 pm |
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
junio 26, 2018 a las 11:40 am |
[…] El artículo completo en La tecla de escapeOtro aquí […]