Hace un par de días hablábamos en twitter sobre la Ley de Demeter, y es una de esas cosas en las que, depende del día, tengo opiniones encontradas, así que me ha parecido una buena escusa para escribir un post y tratar de analizar sus puntos buenos y malos.

La Ley de Demeter

La Ley de Demeter es un principio de diseño que intenta limitar el acoplamiento entre componentes mediante la aplicación de unas reglas muy simples. Cuando hablamos de diseño orientado a objetos, podríamos resumirla de la siguiente forma:

Un método M de un objeto O, sólo puede invocar métodos en los siguientes objetos:

1. El propio objeto O, es decir, el objeto que contiene al método.
2. Los parámetros que recibe el método.
3. Los objetos instanciados por el método, es decir, variables locales creadas en el método.
4. Los objetos contenidos directamente en el objeto O.
5. Los objetos accesibles globalmente desde el método M.

Dicho así puede resultar un poco confuso, pero la idea es fácil: no hay que encadenar llamadas sobre los valores de retorno de los métodos. Es decir, hay que evitar cosas como ésta:

public class DrawEngine
{
  public void Draw(Canvas canvas, Box box)
  {
    canvas.SetColor(box.Border.Color);
    canvas.DrawRectangle(box.Location.X, box.Location.Y, 
                         box.Size.Width, box.Size.Height);

    canvas.SetColor(box.BackColor);
    canvas.FillRectangle(box.Location.X, box.Location.Y, 
                         box.Size.Width, box.Size.Height);
  }
}

En ese método estamos encadenando accesos a la estructura interna de un objeto Box para poder pintarlo en pantalla (Box.Location.X, Box.Border.Color, etc.). Al hacer esto estamos acoplando el código cliente (el método Draw) a la estructura interna del objeto Box, por lo que si en algún momento decidimos cambiar esa estructura, también tendremos que cambiar el código cliente.

La forma directa de evitar esto es encapsular el acceso completo a las propiedades que necesitamos:

public class DrawEngine
{
  public void Draw(Canvas canvas, Box box)
  {
    canvas.SetColor(box.BorderColor);
    canvas.DrawRectangle(box.X, box.Y, box.Width, box.Height);
    canvas.SetColor(box.BackColor);
    canvas.FillRectangle(box.X, box.Y, box.Width, box.Height);
  }
}

public class Box
{
  public int X { get { return location.X; } }
  public int Y { get { return location.X; } }
  public int Width { get { return size.Width; } }
  public int Height { get { return size.Height; } }
  public int BorderColor { get { return border.Color; } }
  // etc...
}

Lo malo de esto es que nos obliga a escribir un montón de código aburrido que lo único que hace es redirigir llamadas a los componentes internos del objeto Box. A cambio, esa capa de indirección nos permite cambiar la estructura interna de Box sin que se vean afectados sus clientes.

Tell, don’t ask

En general, muchas de las violaciones de la Ley de Demeter podemos verlas como un caso de Feature Envy (Envidia de Características), porque tenemos una clase que intenta saber demasiado sobre otra (envidia el conocimiento que tiene la otra).

Para solventar esto, una buena solución es aplicar el principio tell, don’t ask (pide, no preguntes), que consiste en pasar la lógica al objeto que contiene la información, en lugar de extraer de él la información y procesarla fuera.

Aplicando eso al ejemplo anterior, tendríamos:

public class DrawEngine
{
  public void Draw(Canvas canvas, Box box)
  {
    box.Draw(canvas);
  }
}

public class Box
{
  public void Draw(Canvas canvas)
  {
    this.border.Draw(canvas, this.location, this.size);
    
    canvas.SetColor(this.color);
    canvas.FillRectangle(this.location.X, this.location.Y, this.size.Width, this.size.Height);
  }
}

public class Border
{
  public void Draw(Canvas canvas, Point location, Size size)
  {
    canvas.SetColor(this.color);
    canvas.DrawRectangle(location.X, location.Y, size.Width, size.Height);    
  }
}

Con este cambio, hemos mejorado nuestro diseño acercando al comportamiento a los datos, dejando todo mucho más encapsulado, fácil de manejar y desacoplado.

Del encapsulado al God Object

Aplicar el principio del tell, don’t ask no está exento de problemas y corremos el riesgo de convertir nuestra clase en una especie de God Object (objeto Dios) que centraliza un montón de operaciones y viola el Principio de Responsabilidad Única.

Supongamos que ahora, además de querer pintar el objeto Box en pantalla, quisiéramos serializarlo a XML.

Si seguimos con la idea anterior de encapsular el comportamiento en la clase Box y sus componentes, estaremos cargándolas con una nueva responsabilidad, y ya tendremos una clase que es a la vez responsable de representar una caja, pintarla en pantalla y serializarla a XML.

Es fácil ver que esta técnica no escala muy bien y que, si en nuestro sistema tenemos muchas operaciones distintas sobre un objeto Box, esa clase se acabará convirtiendo en algo monstruoso.

Conclusiones

La Ley de Demeter y el principio de tell, don’t ask son unas buena guías para intentar diseñar componentes poco acoplados y conseguir un diseño que sea fácil de evolucionar, pero no dejan de ser eso, guías.

En el diseño de sistemas reales es difícil (¿imposible?) encontrar reglas que podamos seguir siempre, y es necesario estar continuamente analizando las ventajas e inconvenientes de aplicarlas.

Lo más importante es tener claro cuáles son los conceptos subyacentes a todas esas leyes y principios que existen sobre el desarrollo de software para ser capaz de comprender qué implicaciones tiene aplicarlos y qué implicaciones tiene saltárselos.