Estás en el blog de Nicolau Roca
Introducción a la Ley de Deméter: cómo escribir código más limpio y mantenible
¿Alguna vez has sentido que tu código se convierte en un laberinto imposible de controlar?
Cuando un proyecto empieza a crecer, el código puede transformarse en una maraña de objetos que dependen unos de otros de formas poco previsibles. Cambias algo en una clase y, sin entender muy bien por qué, se rompe otra parte del sistema. Si has vivido esa situación, el problema no suele ser solo “código feo”: suele ser un problema de diseño, acoplamiento y conocimiento excesivo entre componentes.
La Ley de Deméter ayuda precisamente a reducir ese ruido. Es un principio sencillo de explicar, pero con un impacto enorme en la calidad del software: cada objeto debería hablar solo con sus colaboradores directos, no navegar por toda la estructura interna del sistema como si conociera cada detalle de implementación.
Qué es la Ley de Deméter
La Ley de Deméter, también conocida como principio de mínimo conocimiento, puede resumirse así:
Un objeto debería hablar solo con sus amigos inmediatos.
En términos más prácticos: un objeto no debería acceder directamente a detalles internos de otros objetos ni encadenar llamadas a objetos que no forman parte de su entorno inmediato. Cuanto más tiene que saber una pieza del sistema sobre la estructura interna de otra, más frágil se vuelve el diseño.
El principio nació en 1987 dentro del proyecto Demeter y se formuló inicialmente en el contexto de la programación orientada a objetos. Aun así, la idea es mucho más amplia: limitar el conocimiento innecesario entre componentes sirve para diseñar mejor en casi cualquier paradigma.
Una analogía sencilla
Imagina que estás en un restaurante. Si quieres pedir comida, hablas con el camarero. No entras en la cocina, buscas al chef, abres la nevera y revisas qué ingredientes hay disponibles. El camarero es tu punto de contacto. Él sabe cómo comunicarse con el resto del sistema.
En código ocurre lo mismo. Si una clase necesita información de otra, debería pedirla a través de una interfaz clara, no atravesar una cadena de objetos internos hasta llegar al dato que busca.
El problema de las cadenas de llamadas
Un síntoma típico de violación de la Ley de Deméter es encontrar código de este estilo:
cliente.getCuenta().getTarjeta().getBanco().validarOperacion()Este fragmento parece cómodo, pero revela un problema: el objeto que ejecuta esa línea conoce demasiada estructura interna. Sabe que el cliente tiene cuenta, que la cuenta tiene tarjeta, que la tarjeta conoce el banco y que el banco valida operaciones. Si cualquiera de esas relaciones cambia, este código queda expuesto.
Una alternativa más mantenible sería encapsular la operación:
cliente.validarOperacion()El objeto cliente, o un servicio responsable, decide internamente cómo resolver esa validación. Desde fuera, el consumidor no necesita conocer todo el recorrido.
Por qué mejora la mantenibilidad
- Reduce acoplamiento: menos objetos dependen de detalles internos de otros.
- Facilita cambios: puedes modificar estructuras internas sin romper consumidores externos.
- Mejora la lectura: el código expresa intención, no mecánica interna.
- Ayuda al testing: las dependencias son más claras y más fáciles de aislar.
- Evita conocimiento innecesario: cada pieza del sistema sabe solo lo que necesita saber.
No se trata de esconderlo todo
Como cualquier principio de diseño, la Ley de Deméter puede aplicarse mal. Si se lleva al extremo, puedes terminar creando demasiados métodos intermedios, demasiadas fachadas y una capa de abstracción innecesaria. El objetivo no es encapsular por deporte, sino reducir dependencias que hacen que el código sea más frágil.
La pregunta útil no es “¿puedo acceder a este dato?”, sino “¿debería esta clase conocer este camino interno?”. Si la respuesta es no, probablemente necesitas rediseñar la colaboración.
El poder de la Ley de Deméter
La Ley de Deméter no es solo una regla técnica. Es una forma de pensar el diseño del software. Obliga a construir relaciones más claras, interfaces más limpias y sistemas menos dependientes de detalles accidentales.
Cuando las interacciones son simples, el software se vuelve más robusto, más mantenible y más fácil de evolucionar. Y eso, en proyectos reales, vale mucho más que escribir una solución rápida que solo entiende quien la hizo.
