Parece simple, pero no lo es. Dos conceptos básicos son muy difíciles de lograr y mantener | de Clemente Morales Fernández | Octubre de 2020

Cuando encontramos nuestro primer lenguaje de programación orientado a objetos, como desarrolladores aprendimos los principios de abstracción, encapsulación, polimorfismo y la herencia del mal.

También nos presentaron el acoplamiento y la cohesión como los dos conceptos básicos de diseño, “alta cohesión y baja unión”, como dicen. Al principio parecía muy simple, pero no lo parece, tenemos muchos proyectos que rompen estas cosas básicas. Comprar ¿por qué? ¿Por qué son difíciles de lograr y luego mantener con el tiempo? ¿Cómo sabemos si nuestro código es consistente y de límite bajo?

Exploremos estos dos conceptos un poco más.

Thicon es la forma en que se diseña una clase con un propósito único y bien dirigido.

Las clases con un propósito bien dirigido tienden a ser más reutilizables que otras clases.

El código relacionado debe estar muy cerca para ser altamente coherente.

Sonar tiene métricas para medir la cohesión: LCOM4

Insuficiente coherencia en los métodos (LCOM4). Esta métrica mide el grado de interconexión de métodos y campos dentro de una clase.

LCOM4 = 1: una clase es un componente fijo con todos los métodos y campos relacionados

LCOM4> 1: La clase se puede dividir en…

Qué tan cerca una clase o módulo apoya un solo propósito o responsabilidad. Es una medida del conocimiento directo que tiene un elemento sobre otro. La unión baja indica una baja dependencia. Una conexión cercana significa que las dos clases a menudo cambian juntas.

Podemos analizar la relación usando un gráfico.

El método de llamada y devolución forma un gráfico de llamadas. El acoplamiento se puede analizar en código utilizando gráficos.

Si creamos un pequeño diagrama con componentes / clases / paquetes y sus dependencias, verá inmediatamente cómo está vinculado su código.

La coherencia y la interconexión también están muy ligadas a otros principios

Cuando una clase es muy cohesiva, solo tiene un trabajo específico. Una responsabilidad separada. Las clases cohesivas son más fáciles de mantener que las clases con muchas responsabilidades.

Ésta es una de las razones para recomendar evitar extensiones como manager o util. No sabemos exactamente cuáles son los deberes de estas clases.

¿Cuántas razones necesitas para cambiar de clase / módulo?

Cada conocimiento debe tener una representación única, inequívoca y autorizada en el sistema.

Tenga cuidado, porque este principio se aplica no solo a la repetición de código, sino también conocimientocoherencia, contexto de código.

Tratar de evitar la repetición de código para diferentes dominios comerciales puede crear código asociado con esos dominios. Si intentamos usar el mismo código nuevamente para otro dominio, es muy posible que su código termine con más de una razón para cambiar.

DRY se trata de un código coherente. Si dos fragmentos de código representan exactamente el mismo conocimiento, siempre cambian juntos.

También conocida como Ley de Deméter. Este principio significa hablar solo con sus amigos inmediatos. Los cambios en una parte del sistema no deben producirse en cascada con las otras partes.

Solo debemos invocar métodos pertenecientes a:

  • El objeto en si
  • Objeto pasado como parámetro al método
  • Cualquier objeto que el método crea o instancia
  • Cualquier objeto definido como variable de instancia en una clase

Este principio nos ayudará a mantener el código menos estrictamente vinculado. Es posible que nuestro código no conozca los detalles de implementación de las dependencias, solo necesitamos un conocimiento limitado.

Tenga cuidado al seguir este principio, porque puede comenzar a agregar más envolventes sin que lo note, lo que significa más capas que afectarán el rendimiento en tiempo de ejecución de su aplicación.

Podemos separar nuestro código usando patrones de diseño e interfaces. Tenemos patrones de diseño GOF, patrones arquitectónicos y principios de diseño. Algunos de estos principios son:

  • Encapsule las cosas que cambian de forma independiente y expóngalas a través de la interfaz.
  • Prefiere la composición a la herencia.
  • Programa de interfaz y no implementación. Depende de las abstracciones, no de las implementaciones específicas.
  • Principios SÓLIDOS.

Si el diseño sigue estos patrones y principios, los nuevos cambios serán más fáciles de aplicar y los costos se reducirán.

Cabe señalar aquí que nuestro código también será más flexible, esta flexibilidad también aumentará la complejidad. Así es compromiso. ¿Cuánta flexibilidad necesitamos?

Cuanto más flexible sea el sistema, más probable es que el sistema pueda adaptarse y evolucionar según sea necesario.
Ralph Johnson
“Gracias al fácil cambio de todo, todo el sistema es muy complicado”

A medida que aumenta la flexibilidad, también aumenta la complejidad. Entonces la pregunta es, ¿cuánta flexibilidad realmente necesitamos? ¿Qué tan bueno es suficiente? ¿Realmente necesitamos estas abstracciones?

¿Cuántos lugares tocó en este último cambio?

¿Ha intentado mover una de las funciones de su aplicación a otro módulo? Uno de los problemas comunes al intentar mover código a otro módulo son las “clases de herramientas”. El código altamente concatenado hará que el código sea muy difícil de mantener.

Al centrarse en la vinculación baja, puede realizar cambios fácilmente en las partes internas de las clases / módulos sin preocuparse por su impacto en otras partes del sistema.

Las clases coherentes facilitan el cambio de código.

Las clases de límite bajo facilitan las pruebas.

Creo que la coherencia y la conectividad es algo que podemos lograr, solo tenemos que dedicar más tiempo a diseñar y verificar el código, especialmente cuando trabajamos de forma remota.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *