Cohesion tells us that proximity follows dependency - simply put, “things that belong togheter should be kept together”
Hay momentos cuando tenemos la necesidad de finalizar un proyecto lo antes posible; probablemente es una de las principales razones para violar el Principio de Cohesión, traten de recordad si tienen una clase que contiene data que no es usada por sus funciones o data que viene de objetos externos.
La violación de este principio conlleva a la duplicación de código, supongamos que existe una función que debe realizar ciertos cálculos basados en la geoposición y decidimos poner tal función dentro de la clase que se supone debe procesar y exponer los datos como un diccionario; aquella función no pertenece a dicha clase y si algún otro desarrollador trata de realizar los mismos cálculos, es probable que duplique el código ya que no es intuitivo para él encontrar dicha función en una clase tan poco relacionada a tal funcionalidad.
La Cohesión simplifica los objetos, facilita la reubicación de variables sueltas y funciones incongruentes con la clase en clases adecuadas a las propiedades en común de tales variables; también reduce la duplicación de código lo que establece ciertos parametros en común que permitan a otros desarrolladores encontrar tales funcionalidades de forma intuitiva.
A properly cohesive design can also allow for optimizations like lazy loading or caching that wouldn’t be possible if the functionality were still spread across the application
La Cohesión está muy relacionada con SRP (Single Responsability Principle) que nos dice que cada clase debe tener una sola funcionalidad bien definida.
Una tarea que Jeff Langr propone en su post es que busquémos en nuestro código funciones con más de 20 líneas y tratemos de romperlas, extrayendo pequeños pedazos lógicos y agrupandolos por común funcionalidad.