La Ley de Demeter ( LoD ) o principio de conocimiento mínimo es una guía de diseño para desarrollar software , particularmente programas orientados a objetos . En su forma general, el LoD es un caso específico de acoplamiento flojo . La directriz fue propuesta por Ian Holland en la Northeastern University hacia finales de 1987, [1] y puede resumirse sucintamente en cada una de las siguientes formas: [2]
- Cada unidad debe tener solo un conocimiento limitado sobre otras unidades: solo unidades "estrechamente" relacionadas con la unidad actual.
- Cada unidad solo debe hablar con sus amigos; no hables con extraños.
- Habla solo con tus amigos inmediatos.
La noción fundamental es que un objeto dado debe asumir lo menos posible sobre la estructura o propiedades de cualquier otra cosa (incluidos sus subcomponentes), de acuerdo con el principio de " ocultación 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 , una programación adaptativa y un esfuerzo de programación orientada a aspectos . El proyecto recibió su nombre en honor a Demeter , "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. [ cita requerida ]
Historia
La ley se remonta a 1987 cuando fue propuesta por primera vez por Ian Holland, quien estaba trabajando en el Proyecto Demeter . El Proyecto Demeter fue el lugar de nacimiento de muchos principios AOP (Programación Orientada a Aspectos).
Una cita en uno de los restos del proyecto parece aclarar el origen del nombre:
Agricultura
La diosa griega de la agricultura.
El proyecto Demeter lleva el nombre de Demeter porque estábamos trabajando en un lenguaje de descripción de hardware Zeus y buscábamos una herramienta para simplificar la implementación de Zeus. Buscábamos un nombre de herramienta relacionado con Zeus y elegimos una hermana de Zeus: Demeter.
Más tarde promocionamos la idea de que el desarrollo de software al estilo Demeter se trata de desarrollar software en lugar de crear software. Introdujimos el concepto de un plan de crecimiento que es básicamente una secuencia de diagramas de clases UML cada vez más complejos.
Los planes de crecimiento son útiles para construir sistemas de forma incremental.
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 "atravesar" el 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 b
la estructura interna del objeto .
En su lugar, b
la interfaz de debe modificarse si es necesario para que pueda atender directamente a
la solicitud del objeto , propagándola a cualquier subcomponente relevante. 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: [3]
a
sí mismo;m
parámetros de;- cualquier objeto instanciado dentro
m
; a
atributos de;- variables globales accesibles por
a
en el alcance dem
.
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 puede expresarse simplemente como "use 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 ordena a las patas del perro que caminen directamente; 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 son menos dependientes de la estructura interna de otros objetos, la implementación del objeto se puede cambiar sin volver a trabajar a sus llamadores.
Basili y col. [4] publicó resultados experimentales en 1996 sugiriendo que una Respuesta para una clase (RFC, el número de métodos potencialmente invocados en respuesta a llamar a un método de esa clase) más baja puede reducir la probabilidad de errores de software . Seguir la Ley de Demeter puede resultar en un RFC más bajo. Sin embargo, los resultados también sugieren que un aumento en los métodos ponderados por clase [5] (WMC, el número de métodos definidos en cada clase) puede aumentar la probabilidad de errores de software. Seguir la Ley de Demeter también puede resultar en un WMC más alto.
Una arquitectura de múltiples capas puede considerarse 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 realizar llamadas al código dentro de la capa y el código dentro de la siguiente capa hacia abajo. El "salto de capa" violaría la arquitectura en capas.
Desventajas
Aunque LoD aumenta la capacidad de adaptación de un sistema de software, puede resultar en tener que escribir muchos métodos de envoltura para propagar llamadas a componentes; en algunos casos, esto puede agregar una sobrecarga notable de tiempo y espacio. [4] [6] [7]
A nivel de método, 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. [8] Por otro lado, a nivel de clase, si el LoD no se usa correctamente, se pueden desarrollar interfaces amplias (es decir, ampliadas) que requieran la introducción de muchos métodos auxiliares. [6] [7] Esto se debe a un diseño deficiente más que a una consecuencia del LoD per se. Si se utiliza un método de envoltura, significa que el objeto que se llama a través de la envoltura debería haber sido una dependencia en la clase de llamada.
Una solución propuesta al problema de las interfaces de clase ampliadas es el enfoque orientado a aspectos , [9] 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 utilizan solo un conjunto mínimo de clases que participan en la operación, y la información sobre las conexiones entre estas clases se extrae.
Ver también
Referencias
- ^ Lieberherr, KJ; Holland, IM (septiembre de 1989). "Garantizar un buen estilo para programas orientados a objetos" . Software IEEE . 6 (5): 38–48. doi : 10.1109 / 52.35588 . ISSN 0740-7459 .
- ^ Macedo, Emerson. "README.markdown: Demeter" . GitHub . Consultado el 5 de julio de 2012 .
- ^ Bock, David. "El repartidor de periódicos, la billetera y la ley de Deméter" (PDF) . Facultad de Ciencias de la Información y la Computación, Northeastern University. pag. 5 . Consultado el 5 de julio de 2012 .
- ^ a b Basili, Víctor; Briand, L .; Melo, WL (octubre de 1996). "Una validación de métricas de diseño orientado a objetos como indicadores de calidad" (PDF) . Transacciones IEEE sobre ingeniería de software . 22 (10): 751–761. doi : 10.1109 / 32.544352 . hdl : 1903/715 .
Como era de esperar, cuanto mayor sea el WMC, mayor será la probabilidad de detección de fallas.
- ^ "Métodos ponderados por clase - Maisqual Wiki" . maisqual.squoring.com . Consultado el 20 de septiembre de 2018 .
- ^ a b Appleton, Brad. "Presentación de Demeter y sus leyes" . Consultado el 6 de julio de 2013 .
Un efecto secundario de esto es que si se ajusta a LoD, aunque puede aumentar bastante la capacidad de mantenimiento y la "adaptabilidad" de su sistema de software, también termina teniendo que escribir muchos métodos de envoltura pequeños para propagar las llamadas de métodos a sus componentes ( lo que puede agregar una sobrecarga notable de tiempo y espacio).
- ^ a b "Dile, no preguntes" . Los programadores pragmáticos, LLC . Consultado el 6 de julio de 2013 .
La desventaja, por supuesto, es que termina escribiendo muchos métodos de contenedor pequeños que hacen muy poco, pero delegan el recorrido del contenedor y demás. La compensación de costos está entre esa ineficiencia y el acoplamiento de clases superiores.
- ^ Lieberherr, K .; Holanda, I .; Riel, A. (1988). "Programación orientada a objetos: un sentido objetivo del estilo" (PDF) . En Meyrowitz, Norman (ed.). Actas de congresos sobre sistemas, lenguajes y aplicaciones de programación orientada a objetos (OOPSLA '88) . ACM. págs. 323–334. doi : 10.1145 / 62083.62113 . ISBN 978-0897912846 (PDF) . Consultado el 5 de julio de 2012 .
Mantenimiento de software más fácil, menor acoplamiento entre sus métodos, mejor ocultación de información, interfaces más estrechas, métodos que son más fáciles de reutilizar y pruebas de corrección más fáciles mediante inducción estructural.
Comprobar|archive-url=
valor ( ayuda ) - ^ Lieberherr, Karl; Orleans, Doug; Ovlinger, Johan (octubre de 2001). "Programación orientada a aspectos con métodos adaptativos" (PDF) . Comun. ACM . 44 (10): 39–40. CiteSeerX 10.1.1.192.6403 . doi : 10.1145 / 383845.383855 . Consultado el 5 de julio de 2012 .
Un método adaptativo encapsula el comportamiento de una operación en un solo lugar, evitando así el problema de la dispersión, pero también abstrae la estructura de clases, evitando así el problema de enredos.
[ enlace muerto permanente ]
Otras lecturas
- Lieberherr, Karl; Holland, I. (septiembre de 1989). "Garantizar un buen estilo para programas orientados a objetos". Software IEEE . 6 (5): 38–48. doi : 10.1109 / 52.35588 .
- Lieberherr, Karl J. (1995). Software adaptativo orientado a objetos: el método Demeter con patrones de propagación . Compañía Editorial PWS. ISBN 978-0534946029.
- Hunt, Andrew; Thomas, David (2002). "5. Doblar o romper § La ley de Demeter para funciones" . El programador pragmático: de jornalero a maestro . Addison-Wesley. págs. 140-1. ISBN 978-0-13-211917-7.
- Larman, Craig (2005). Aplicando UML y Patrones (3ª ed.). Prentice Hall. págs. 430-2. (de este libro, la "Ley de Deméter" también se conoce como "No hables con extraños")
- McConnell, Steve (2004). Código completo (2ª ed.). Microsoft Press. págs. 150 .
- Palermo, Jeffrey; Scheirman, Ben; Bogard, Jimmy (2009). ASP.NET MVC en acción . Publicaciones Manning. pag. 14.
enlaces externos
- Ley de Demeter (LoD)
- "Programación orientada a objetos: un sentido objetivo del estilo" (Actas de OOPSLA '88) (PDF)
- El repartidor de periódicos, la billetera y la ley de Deméter (PDF)
- Phil Haack: "La ley de Deméter no es un ejercicio de conteo de puntos"
- Lieber: "Ley de Deméter de Phil Holland"
- "Software adaptable orientado a objetos, el método Demeter"
- El Proyecto Demeter —- ¿Qué es Demeter?