Ley de Deméter

La Ley de Deméter (LoD) o principio del mínimo conocimiento es una guía de diseño para desarrollar software, particularmente programas orientados a objetos. En su forma general, la LoD es un caso específico de acoplamiento débil. La directriz fue propuesta por Ian Holland en la Universidad Northeastern a fines de 1987, y las siguientes tres recomendaciones sirven como resumen sucinto:

• Cada unidad debe tener sólo conocimiento limitado sobre otras unidades: sólo unidades "cercamente" relacionadas con la unidad actual.
• Cada unidad sólo debe hablar con sus amigos; no hable con extraños.
• Sólo habla con tus amigos inmediatos.

La noción fundamental es que un objeto determinado debe suponer lo menos posible sobre la estructura o las propiedades de cualquier otra cosa (incluidos sus subcomponentes), de acuerdo con el principio de "ocultamiento de información". Puede verse como un corolario del principio de privilegio mínimo, que dicta que un módulo posee solo la información y los recursos necesarios para su propósito legítimo.

Se llama así por su origen en el Proyecto Demeter, un esfuerzo de programación adaptativa y programación orientada a aspectos. El proyecto recibió su nombre en honor a Deméter, "madre de la distribución" y la diosa griega de la agricultura, para significar una filosofía de programación de abajo hacia arriba que también está incorporada en la ley misma.

Historia

La ley data de 1987 cuando Ian Holland la propuso por primera vez, quien estaba trabajando en el Proyecto Demeter. El Proyecto Demeter fue el lugar de nacimiento de muchos principios de AOP (Programación Orientada a Aspectos).

Una cita en uno de los restos del proyecto parece aclarar los orígenes del nombre:

Agricultura

La diosa griega de la agricultura.

El proyecto Demeter fue nombrado por Demeter porque estábamos trabajando en un lenguaje de descripción de hardware Zeus y estábamos buscando una herramienta simplificar la implementación de Zeus. Buscamos un nombre de herramienta. relacionado con Zeus y elegimos una hermana de Zeus: Demeter.

Más tarde promovimos la idea de que el desarrollo de software de estilo Demeter es sobre el crecimiento de software en lugar de construir software. Introducimos el concepto de un plan de crecimiento que es básicamente una secuencia de diagramas de clase UML más y más complejos.

Los planes de crecimiento son útiles para los sistemas de construcción incrementalmente.

En programación orientada a objetos

Un objeto a puede solicitar un servicio (llamar a un método) de una instancia de objeto b, pero el objeto a no debe "llegar a través de" objeto b para acceder a otro objeto, c, para solicitar sus servicios. Hacerlo significaría que el objeto a implícitamente requiere un mayor conocimiento de la estructura interna del objeto b.

En su lugar, la interfaz de b debe modificarse si es necesario para que pueda atender directamente la solicitud del objeto a, propagándola a cualquier subcomponentes. Alternativamente, a podría tener una referencia directa al objeto c y hacer la solicitud directamente a eso. Si se sigue la ley, solo el objeto b conoce su propia estructura interna.

Más formalmente, la Ley de Deméter para funciones requiere que un método m de un objeto a solo pueda invocar los métodos de los siguientes tipos de objetos:

• a en sí mismo;
• m's parámetros;
• cualquier objeto instantánea dentro m;
• a's atributos;
• variables globales accesibles por a en el ámbito m.

En particular, un objeto debe evitar invocar métodos de un objeto devuelto por otro método. Para muchos lenguajes modernos orientados a objetos que usan un punto como identificador de campo, la ley se puede establecer simplemente como "usar solo un punto". Es decir, el código a.m().n() infringe la ley donde a.m() no lo hace. Como analogía, cuando uno quiere que un perro camine, no le ordena directamente a las patas del perro que camine; en cambio, uno manda al perro que luego manda a sus propias piernas.

Ventajas

La ventaja de seguir la Ley de Demeter es que el software resultante tiende a ser más fácil de mantener y adaptable. Dado que los objetos dependen menos de la estructura interna de otros objetos, la implementación del objeto se puede cambiar sin volver a trabajar con sus llamadores.

Basili et al. publicaron resultados experimentales en 1996 que sugieren que una menor Respuesta para una clase (RFC, el número de métodos potencialmente invocados en respuesta a llamar a un método de esa clase) puede reducir la probabilidad de errores de software. Seguir la Ley de Deméter puede resultar en un RFC más bajo. Sin embargo, los resultados también sugieren que un aumento en métodos ponderados por clase (WMC, la cantidad de métodos definidos en cada clase) puede aumentar la probabilidad de errores de software. Seguir la Ley de Deméter también puede resultar en un WMC más alto.

Se puede considerar que una arquitectura multicapa es un mecanismo sistemático para implementar la Ley de Demeter en un sistema de software. En una arquitectura en capas, el código dentro de cada capa solo puede hacer llamadas al código dentro de la capa y al código dentro de la siguiente capa. "Salto de capa" violaría la arquitectura en capas.

Desventajas

Aunque la LoD aumenta la capacidad de adaptación de un sistema de software, puede resultar en tener que escribir muchos métodos de envoltorio para propagar las llamadas a los componentes; en algunos casos, esto puede agregar una sobrecarga considerable de tiempo y espacio.

A nivel de método, el LoD conduce a interfaces estrechas, dando acceso solo a la información que necesita para hacer su trabajo, ya que cada método necesita conocer un pequeño conjunto de métodos de objetos estrechamente relacionados. Por otro lado, a nivel de clase, si el LoD no se usa correctamente, se pueden desarrollar interfaces amplias (es decir, ampliadas) que requieren la introducción de muchos métodos auxiliares. Esto se debe a un diseño deficiente y no a una consecuencia de la LoD per se. Si se utiliza un método contenedor, significa que el objeto al que se llama a través del contenedor debería haber sido una dependencia en la clase que llama.

Una solución propuesta al problema de las interfaces de clases ampliadas es el enfoque orientado a aspectos, donde el comportamiento del método se especifica como un aspecto con un alto nivel de abstracción. Las amplias interfaces se gestionan a través de un lenguaje que especifica implementaciones. Tanto la estrategia transversal como el visitante adaptativo usan solo un conjunto mínimo de clases que participan en la operación, y la información sobre las conexiones entre estas clases se abstrae.