¿Qué es la cohesión lógica y por qué es mala o indeseable?

Desde la página de c2wiki sobre acoplamiento y cohesión :

Nombres de fuerza / nivel de cohesión (interdependencia dentro del módulo): (de peor a mejor, la alta cohesión es buena)

• Cohesión coincidente: (Peor) Los elementos del módulo no están relacionados
• Cohesión lógica: los elementos realizan actividades similares a las seleccionadas desde el módulo externo, es decir, mediante un indicador que selecciona la operación a realizar (consulte también CommandObject). es decir, el cuerpo de la función es un enorme indicador if-else / switch on operation
• Cohesión temporal: operaciones relacionadas solo por el tiempo general realizado (es decir, inicialización () o FatalErrorShutdown? ())
• Cohesión de procedimiento: Elementos involucrados en actividades diferentes pero secuenciales, cada uno con datos diferentes (por lo general, podrían dividirse trivialmente en múltiples módulos a lo largo de los límites de secuencia lineal)
• Cohesión comunicacional: operaciones no relacionadas, excepto que necesitan los mismos datos o entrada
• Cohesión secuencial: operaciones en los mismos datos en orden significativo; la salida de una función se ingresa a la siguiente (canalización)
• Cohesión informativa: un módulo realiza una serie de acciones, cada una con su propio punto de entrada, con un código independiente para cada acción, todo realizado en la misma estructura de datos. Esencialmente, una implementación de un tipo de datos abstracto. es decir, definir la estructura de sales_region_table y sus operadores: init_table (), update_table (), print_table ()
• Cohesión funcional: todos los elementos contribuyen a una tarea única y bien definida, es decir, una función que realiza exactamente una operación get_engine_temperature (), add_sales_tax ()

(énfasis mío).

No entiendo completamente la definición de cohesión lógica. Mis preguntas son:

• ¿Qué es la cohesión lógica?
• ¿Por qué tiene tan mala reputación (segundo peor tipo de cohesión)?

La cohesión lógica puede ser mala porque terminas agrupando la funcionalidad por características técnicas en lugar de características funcionales. Por ejemplo, considere una aplicación que consta de múltiples módulos. Cada módulo representa un dominio comercial y tiene el código de acceso a datos correspondiente. Si agrupa todos los códigos de acceso a datos en todos los módulos, entonces tiene cohesión lógica. Después de todo, todo es acceso a datos y, en algunos casos, es beneficioso poder evaluar los patrones de acceso a datos de una aplicación. Sin embargo, esto es problemático porque el dominio empresarial proporciona los límites del módulo, no el dominio técnico. Al lograr la cohesión lógica, terminas perdiendo la cohesión funcional. Por lo general, el dominio empresarial define una unidad de implementación bien definida y los aspectos técnicos están ahí para admitir el dominio empresarial.

Por cómo se describe, diría que se trata de acoplar código que tiene cierta cohesión, pero rompe la orientación del objeto.

Ejemplo: cálculo del área de un polígono. Cuando pone el cálculo del cuadrado junto con el cálculo del triángulo, y solo elige por el parámetro de entrada, entonces ha agrupado dos cosas lógicamente por su resultado, sin tener en cuenta su naturaleza real.

Mi opinión personal es que el logicaltérmino fue elegir mal y conduce a la confusión. Tendemos a pensar que eso logicales bueno. En muchos escenarios functionalse puede intercambiar con logical.

Reemplazaría logicalcon technical término porque su enfoque en la parte técnica en lugar de en (y quiero usar palabras logicalaquí, pero será engañoso en el contexto de esta discusión) lo que este componente hace para todo el sistema.

Un ejemplo típico puede ser la agrupación de clases que proporcionan puntos finales para algunas API.
Si los agrupa en alguna carpeta porque proporcionan puntos finales, es a technical cohesion. Si los agrupa porque proporcionan alguna funcionalidad (como la lista de usuarios de administración, por ejemplo) es unfunctional cohesion

Además, también desafiaría el functionaltérmino aquí porque es demasiado amplio. Puede referir la función como construcción de sintaxis, así como la funcionalidad de una cosa. En el ejemplo anterior, una clase de punto final tiene 2 funcionalidades: punto final y lógica de negocios.

Yo reemplazaría functionala logical. Hace referencia a business logic, hace referencia al logical viewmodelo de vista de software 4 + 1 y, en general, tenemos una tendencia a llamar a las cosas "lógicas" cuando tienen razón.