cohesion - que - ¿Qué es una alta cohesión y cómo usarla/hacerla?
tags h1 ejemplos (9)
Estoy aprendiendo programación de computadoras y en varios lugares he tropezado con el concepto de cohesión y entiendo que es deseable que un software tenga "alta cohesión", pero ¿qué significa? Soy un programador de Java, C y Python aprendiendo C ++ del libro C ++ Primer que menciona la cohesión sin tenerlo en el índice, ¿podría indicarme algunos enlaces sobre este tema? No encontré informativa la página de wikipedia sobre cohesión en informática porque solo dice que es una medida cualitativa y no da ejemplos de código real.
Alta cohesión es cuando tienes una clase que hace un trabajo bien definido. Baja cohesión es cuando una clase hace muchos trabajos que no tienen mucho en común.
Tomemos este ejemplo:
Tienes una clase que agrega dos números, pero la misma clase crea una ventana que muestra el resultado. Esta es una clase baja cohesiva porque la ventana y la operación de adición no tienen mucho en común. La ventana es la parte visual del programa y la función de adición es la lógica detrás de ella.
Para crear una solución altamente cohesiva, debería crear una clase de ventana y una clase de suma. La ventana llamará al método de Sum para obtener el resultado y mostrarlo. De esta forma, desarrollará por separado la lógica y la GUI de su aplicación.
El término cohesión se utilizó originalmente para describir los módulos de código fuente como una medida cualitativa de qué tan bien el código fuente del módulo se relacionó entre sí. La idea de cohesión se usa en una variedad de campos. Por ejemplo, un grupo de personas, como una unidad militar, puede ser cohesivo, lo que significa que las personas de la unidad trabajan juntas hacia un objetivo común.
La esencia de la cohesión del código fuente es que el código fuente en un módulo trabaja en conjunto hacia un objetivo común y bien definido. La cantidad mínima de código fuente necesaria para crear las salidas del módulo está en el módulo y no más. La interfaz está bien definida y las entradas fluyen a través de la interfaz y las salidas fluyen a través de la interfaz. No hay efectos secundarios y el énfasis está en el minimalismo.
Un beneficio de los módulos funcionalmente cohesivos es que desarrollar y automatizar las pruebas unitarias es sencillo. De hecho, una buena medida de la cohesión de un módulo es lo fácil que es crear un conjunto completo de pruebas exhaustivas de la unidad para el módulo.
Un módulo puede ser una clase en un lenguaje orientado a objetos o una función en un lenguaje funcional o lenguaje no orientado a objetos como C. Gran parte del trabajo original en esta área de medición de la cohesión involucraba principalmente el trabajo con programas COBOL en IBM en el Década de 1970, entonces la cohesión definitivamente no es solo un concepto orientado a objetos.
La intención original de la investigación de la cual proviene el concepto de cohesión y el concepto asociado de acoplamiento fue la investigación de qué características de los programas eran fáciles de comprender, mantener y ampliar. El objetivo era poder aprender las mejores prácticas de programación, codificar esas mejores prácticas y luego enseñar las prácticas a otros programadores.
El objetivo de los buenos programadores es escribir un código fuente cuya cohesión sea lo más alta posible dado el entorno y el problema que se está resolviendo. Esto implica que en una aplicación grande algunas partes del cuerpo del código fuente variarán de otras partes en cuanto al nivel de cohesión del código fuente en ese módulo o clase. Algunas veces, lo mejor que puede obtener es cohesión temporal o secuencial debido al problema que está tratando de resolver.
El mejor nivel de cohesión es la cohesión funcional. Un módulo con cohesión funcional es similar a una función matemática, ya que proporciona un conjunto de entradas y obtiene un resultado específico. Un módulo verdaderamente funcional no tendrá efectos secundarios además de la salida ni mantendrá ningún tipo de estado. En su lugar, tendrá una interfaz bien definida que encapsula la funcionalidad del módulo sin exponer ninguno de los componentes internos del módulo y la persona que utiliza el módulo proporcionará un conjunto particular de entradas y obtendrá un rendimiento particular a cambio. Un módulo verdaderamente funcional también debería ser seguro para subprocesos.
Muchas bibliotecas de lenguaje de programación contienen una cantidad de ejemplos de módulos funcionales ya sean clases, plantillas o funciones. Los ejemplos cohesivos más funcionales serían las funciones matemáticas como pecado, coseno, raíz cuadrada, etc.
Otras funciones pueden tener efectos secundarios o mantener el estado de algún tipo, lo que hace que el uso de esas funciones sea más complicado.
Por ejemplo, una función que arroja una excepción o establece una variable de error global ( errno en C) o debe usarse en una secuencia (la strtok() es un ejemplo de la biblioteca Standard C ya que mantiene un estado interno) o que proporciona una el puntero que debe ser administrado o emite un log a alguna utilidad de registro son todos ejemplos de una función que ya no es cohesión funcional.
He leído el libro original de Yourdon y Constantine, Structured Programming, donde descubrí por primera vez la idea de la cohesión en la década de 1980 y el libro de Meilir Page-Jones, Guía práctica para el diseño de sistemas estructurados, y Page-Jones hizo un trabajo mucho mejor al describir ambos acoplamiento y cohesión. El libro de Yourdon y Constantino parece un poco más académico. El libro de Steve McConnell Code Complete es bastante bueno y práctico, y la edición revisada tiene bastante que decir acerca de las buenas prácticas de programación.
Este es un ejemplo de baja cohesión:
class Calculator
{
public static void main(String args[])
{
//calculating sum here
result = a + b;
//calculating difference here
result = a - b;
//same for multiplication and division
}
}
Pero una alta cohesión implica que las funciones en las clases hacen lo que se supone que deben hacer (como se nombran). Y no una función que hace el trabajo de alguna otra función. Entonces, lo siguiente puede ser un ejemplo de alta cohesión:
class Calculator
{
public static void main(String args[])
{
Calculator myObj = new Calculator();
System.out.println(myObj.SumOfTwoNumbers(5,7));
}
public int SumOfTwoNumbers(int a, int b)
{
return (a+b);
}
//similarly for other operations
}
La alta cohesión es un concepto de ingeniería de software. Básicamente, dice que una clase solo debe hacer lo que se supone que debe hacer, y lo hace completamente. No lo sobrecargue con funciones que se supone que no debe hacer, y cualquier cosa directamente relacionada con él no debería aparecer en el código de alguna otra clase tampoco.
El ejemplo es bastante subjetivo, ya que también debemos considerar la escala. Un programa simple no debe ser demasiado modular o se fragmentará; mientras que un programa complejo puede necesitar más nivel de abstracciones para encargarse de la complejidad.
por ejemplo, clase de correo electrónico. Debe contener miembros de datos, from, cc, bcc, subject, body, y puede contener estos métodos saveAsDraft (), send (), discardDraft (). Pero login () no debería estar aquí, ya que hay un número de protocolo de correo electrónico, y debe implementarse por separado.
La cohesión generalmente se mide utilizando una de las métricas de LCOM (falta de cohesión), la métrica LCOM original provino de Chidamber y Kemerer. Ver por ejemplo: http://www.computing.dcu.ie/~renaat/ca421/LCOM.html
Un ejemplo más concreto: si una clase tiene, por ejemplo, un campo privado y tres métodos; cuando los tres métodos usan este campo para realizar una operación, la clase es muy cohesionada.
Pseudo código de una clase cohesiva:
class FooBar {
private SomeObject _bla = new SomeObject();
public void FirstMethod() {
_bla.FirstCall();
}
public void SecondMethod() {
_bla.SecondCall();
}
public void ThirdMethod() {
_bla.ThirdCall();
}
}
Si una clase tiene, por ejemplo, tres campos privados y tres métodos; cuando los tres métodos usan solo uno de los tres campos, la clase no está bien cohesionada.
Pseudo código de una clase pobremente cohesiva:
class FooBar {
private SomeObject _bla = new SomeObject();
private SomeObject _foo = new SomeObject();
private SomeObject _bar = new SomeObject();
public void FirstMethod() {
_bla.Call();
}
public void SecondMethod() {
_foo.Call();
}
public void ThirdMethod() {
_bar.Call();
}
}
El principio de clase haciendo una cosa es el principio de responsabilidad única que proviene de Robert C. Martin y es uno de los principios SOLID . El principio prescribe que una clase debe tener solo una razón para cambiar.
Mantenerse cerca del Principio de Responsabilidad Individual podría resultar en un código más cohesivo, pero en mi opinión, estas son dos cosas diferentes.
Una explicación de lo que es del Código Completo de Steve McConnell:
La cohesión se refiere a qué tan cerca todas las rutinas en una clase o todo el código en una rutina respaldan un propósito central . Se describe que las clases que contienen una funcionalidad fuertemente relacionada tienen una fuerte cohesión, y el objetivo heurístico es hacer que la cohesión sea lo más fuerte posible. La cohesión es una herramienta útil para manejar la complejidad porque cuanto más código en una clase respalda un propósito central, más fácilmente su cerebro puede recordar todo lo que hace el código.
Alguna forma de lograrlo del Código Limpio del Tío Bob:
Las clases deben tener un pequeño número de variables de instancia . Cada uno de los métodos de una clase debe manipular una o más de esas variables. En general, cuantas más variables manipule un método, más cohesivo será ese método para su clase. Una clase en la que cada variable es utilizada por cada método es cohesiva máxima.
En general, no es aconsejable ni posible crear tales clases de máximo cohesión; por otro lado, nos gustaría que la cohesión sea alta. Cuando la cohesión es alta, significa que los métodos y variables de la clase son co-dependientes y se mantienen unidos como un todo lógico.
La noción de cohesión está fuertemente relacionada con la noción de acoplamiento; también, hay un principio basado en la heurística de alta cohesión, llamado Principio de Responsabilidad Individual (el S de SOLID).
Una forma general de pensar en el principio de cohesión es ubicar un código junto con otro que dependa de él o del que dependa. La cohesión puede y debe aplicarse a los niveles de composición por encima del nivel de clase. Por ejemplo, un paquete o espacio de nombres idealmente debería contener clases que se relacionen con un tema común, y que sean más fuertemente dependientes que dependan de otros paquetes / espacios de nombres. Es decir, mantener las dependencias locales.
cohesión significa que una clase o un método hace solo un trabajo definido. el nombre del método o clase también debe ser autoexplicativo. por ejemplo, si escribe una calculadora debe nombrar la clase "calculadora" y no "asdfghj". también debería considerar crear un método para cada tarea, por ejemplo, restar () agregar (), etc ... el programador que podría usar su programa en el futuro sabe exactamente lo que están haciendo sus métodos. un buen nombre puede reducir los esfuerzos para comentar
también un principio es SECO - no te repitas