Cada unidad debe tener un conocimiento limitado sobre otras unidades: sólo las unidades \»estrechamente\» relacionadas con la unidad actual. O: Cada unidad solo debe hablar con sus amigos; No hables con extraños.
Traducción de: https://www2.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/general-formulation.html
La Ley de Demeter (LoD) fue formulada originalmente como una regla de estilo para el diseño de sistemas orientados a objetos. \»Sólo habla con tus amigos inmediatos\». La regla de estilo fue descubierta en la Universidad Northeastern en el otoño de 1987 por Ian Holland.
Una formulación más general de la Ley de Deméter es: Cada unidad debe tener un conocimiento limitado sobre otras unidades: sólo las unidades \»estrechamente\» relacionadas con la unidad actual. O: Cada unidad solo debe hablar con sus amigos; No hables con extraños.
En esta forma general, el LoD es un caso más específico del Principio de Bajo Acoplamiento bien conocido en ingeniería de software. El Principio de Bajo Acoplamiento es muy general y tratamos de hacerlo más específico. El beneficio de la Ley específica de Demeter que se muestra a continuación es que hace que la noción de acoplamiento innecesario sea muy explícita.
La principal motivación de la Ley de Demeter es controlar la sobrecarga de información; sólo podemos mantener un conjunto limitado de elementos en la memoria a corto plazo y es más fácil mantenerlos en la memoria si están estrechamente relacionados. La definición de \»estrechamente relacionada\» se deja intencionalmente vaga para que pueda adaptarse a circunstancias particulares.
En la aplicación de LoD al diseño y programación orientados a objetos tenemos:
unidad : método f
métodos de clase de clase this/self de f y otras clases de argumento de f y métodos de clases de pieza inmediatas (tanto calculadas como almacenadas) de clase de f (clases que son tipos de retorno de métodos de clase de this/self (-calculado) y las clases de miembros de datos ( •almacenado)) y métodos de clases de objetos que se crean en f.
Lo anterior es la forma de clase de la Ley de Demeter que tiene la ventaja de ser eficientemente computable. Sin embargo, es la Forma Objeto de la Ley de Demeter la que expresa la regla de estilo que realmente queremos. Desafortunadamente, si un programa satisface la forma del objeto es indeciso. Sin embargo, podemos ejecutar el programa y comprobar en tiempo de ejecución si se producen infracciones (este es un buen ejercicio en la programación orientada a aspectos).
Rumbaugh resume la Ley de Deméter como: Un método debe tener un conocimiento limitado de un modelo de objetos. Esta visión conduce a una programación orientada a los aspectos: sacamos el método y transitivamente todos sus métodos auxiliares en un aspecto separado. Esto funciona mejor si el aspecto independiente tiene un conocimiento limitado sobre el modelo de objetos.
La Ley de Deméter y las interfaces estrechas y anchas (iniciadapor Mitch Wand 2003, invitaron a hablar en ICFP 2003):
En el nivel de método, el LoD conduce a interfaces estrechas porque cada método necesita saber acerca de un pequeño conjunto de métodos de objetos estrechamente relacionados. Por otro lado, en el nivel de clase, el LoD conduce a interfaces anchas porque el LoD requiere que introduzcamos muchos métodos auxiliares en lugar de cavar directamente en las estructuras de objetos. Las interfaces anchas para las clases son un problema y la solución es un enfoque orientado a aspectos donde el comportamiento del método se especifica como un aspecto en un alto nivel de abstracción. Todavía tenemos interfaces amplias, pero las administramos a través de un lenguaje que especifica las implementaciones.