Una pauta de diseño de software (también llamada principio del menor conocimiento) que prescribe que un módulo solo debe comunicarse con sus colaboradores inmediatos (sí mismo, sus campos, parámetros, objetos que crea y sus componentes directos) para reducir el acoplamiento y limitar el conocimiento de la estructura interna.

Principio

Minimizar el acoplamiento y la exposición de información restringiendo el conjunto de objetos que un módulo utiliza directamente, mejorando la modularidad y la sustituibilidad y evitando largas cadenas de llamadas delegadas.

Demostración

Ejemplo concreto: en vez de client.methodA().methodB().doWork(), el cliente debe pedir al objeto de nivel superior que realice la operación necesaria o exponer una interfaz concisa para que el cliente no recorra el grafo de objetos interno; esto reduce dependencias frágiles sobre internos de objetos.

Aplicación incorrecta

Aplicar la ley de Demeter de forma dogmática puede producir métodos envoltorio excesivos, interfaces anémicas o responsabilidades demasiado fragmentadas que dañen la claridad o el rendimiento; por el contrario, evitar toda delegación puede duplicar lógica y reducir la reutilización.

Consecuencia

Cuando se aplica con equilibrio, reduce el acoplamiento accidental, facilita la refactorización y mejora la encapsulación y la capacidad de prueba; puede, sin embargo, aumentar el número de métodos de reenvío o exigir interfaces fachada diseñadas intencionadamente.

Inversión

El enfoque inverso permite que los módulos atraviesen y manipulen libremente grafos de objetos internos profundos, aumentando expresividad pero también creando acoplamientos fuertes e interdependencias frágiles.

Límite

Una heurística para diseño orientado a objetos y de componentes, no una regla absoluta: apunta al acoplamiento a nivel de sitio de llamada y no prescribe compensaciones de implementación interna, decisiones de arquitectura por capas ni el uso de datos inmutables compartidos.

Tensión semántica

Tensión entre la estricta reducción de acoplamiento que recomienda la ley y preocupaciones pragmáticas como el rendimiento, la claridad y evitar la repetición excesiva de código; tensión entre reglas locales de uso de mensajes y patrones arquitectónicos de alto nivel (por ejemplo, visitor, APIs fluidas).

Síntesis

La ley de Demeter recomienda restringir las interacciones directas a colaboradores inmediatos para disminuir el acoplamiento y mejorar la modularidad; aplicada con juicio, mejora la mantenibilidad, pero su aplicación excesiva o acrítica genera otros costes que deben ponderarse.