LEY DE DEMETER

la «Ley de Deméter para Funciones», pero eso es un nombre dogmático. Como la mayoría de las «leyes» en desarrollo de software, es más de un buena idea que una constante física de el universo. Esta buena idea sugiere que un objeto sólo debería llamar

• En sí mismo.
• Cualquier parámetro que se pasó en el método.
• Cualquier objeto que haya creado.
• Cualquier componente directamente sostenido objetos.

EJEMPLO DONDE NO USAMOS ESTA LEY

Queremos prender un televisor

mi_television.front_panel.switches.power.on(); El acceso directo de un hijo como este extiende el acoplamiento desde el llamador más allá de lo necesario. El llamador está depende de la navegación del objeto tal que:

• Un objeto Televisión tiene un panel.
• Un panel frontal tiene algunos interruptores.
• Uno de esos interruptores es "power".
• El poder tiene un método de "encendido", que encenderá el televisor

EJEMPLO USANDO ESTA LEY

Queremos prender un televisor

my_television. power_up ();

Ahora el llamante no necesita conocimiento del modelo de objeto interno de my_television. Esta lamada de nivel superior suena más como un requisito del usuario y menos como un detalle de implementación, lo que significa que estamos programando más cerca del dominio del problema también

La desventaja de este enfoque es que acabas escribiendo muchos pequeños métodos envolventes que hacen muy poco pero delegan el recorrido del contenedor y y cosas por el estilo.

El coste de la compensación es la ineficiencia frente a un mayor acoplamiento de la clase. En el largo plazo (e incluso en el corto plazo en algunos casos), un mayor acoplamiento de clase es simplemente inaceptable, ya que aumenta las probabilidades de que cualquier cambio que hagas rompa algo en otra parte. No se necesita mucho acoplamiento de clase alta para crear un montón de código frágil y quebradizo.