Si buscamos en google “ley de demeter” el primer resultado que nos encontramos nos indica:

La ley de Demeter es un principio básico de la programación orientada a objetos. Sorprende al conocerlo su gran utilidad, sus resultados en proyectos de todos los tamaños y el poco conocimiento que la comunidad de desarrolladores tiene de su existencia. 7 ene. 2008

Curioso, ciertamente estos principios no son todavía muy conocidos en la comunidad de desarrolladores, por este motivo, hace unas semanas decidimos hacer un pequeño workshop en el equipo en el que trabajo para dejar claro de qué se trata y cuales son éstos principios.

Si buscamos la definición de “ley de demeter” en Wikipedia esto es lo que nos indica (resumiendo):

La Ley de Demeter o Principio del Menor Conocimiento es una directriz utilizada en la Programación Orientada a Objetos.

En su forma general, la LoD es un caso específico de loose coupling (bajo acoplamiento).

Bien, en realidad yo lo resumiría con la siguiente frase: NUNCA HABLES CON EXTRAÑOS.

La Ley de demeter dice que el método de un objeto solo puede llamar a métodos de:

  1. El propio objeto.
  2. Un argumento del método.
  3. Cualquier objeto creado dentro del método.
  4. Cualquier propiedad/campo directo del propio objeto.

Deberíamos evitar casos como este:

getX().getY().getZ().doSomething()

¿Qué pasa si getX cambia, y no necesita una referencia a getY?
¿Y si luego getY ya no necesita una referencia a getZ?
Esta clase no es reutilizable porque al usarla necesitas de otras clases.

Para cumplir la LoD siguiendo con el ejemplo anterior podríamos escribirlo así:

val x = getX()
val y = getY()
val z = getZ()
z.doSomething()

¿Cómo solucionamos las violaciones de la LoD?.

1. Añade métodos extra.

getX().doSomething()
getY().doSomething()

2. Evita la concatenación.

getX().doSomething().doSomethingElse()
getX().doSomething() STOP

3. Arquitectura.

Con una buena arquitectura cada capa tendrá una serie de interfaces con las que comunicarse y ocultarán su implementación.

4. Comprender mejor tu dominio.

No entender nuestro dominio puede desembocar en que no modelemos bien la aplicación.

Beneficios de cumplir la LoD.

  1. Se reducen las dependencias entre clases y el acoplamiento.
  2. Se vuelve más sencillo reutilizar las clases.
  3. El código es más facil de probar.
  4. El código es más mantenible y flexible a los cambios.

Así que ya sabes, no violes la Ley de Demeter.