LA LEY DE DEMETER PARA SISTEMAS ORIENTADOS A OBJETOS

Law of Demeter

De la web: Demetrio es el dios griego de la agricultura: construye el software en pequeños pasos

En este enlace se da una definición un poco más detallada: cada unidad sólo debe tener conocimiento limitado acerca de otras unidades: sólamente unidades "cercanas entre sí" deben conocerse: no hables con extraños.

Realmente, esto ya se ha discutido en clase tanto de Ingeniería del Software como en Distribuidos cuando se habla de obtener una cohesión máxima, pero un acoplamiento mínimo. La Ley de Demeter busca el desacoplamiento entre elementos para obtener una arquitectura en capas que permita su reutilización y su facilidad de cambio y ampliación.

Según los artículos enlazados en la página, esta idea de limitación de conocimiento por parte de elementos -o métodos- da pie a la Programación Orientada a Aspectos -AOP-.

En este otro enlace se define la ley de Demeter para Objetos, que, resumiendo, viene a decir que dentro de un método sólo se pueden enviar mensajes a objetos que sean parámetros del método, a métodos de él mismo, a objetos creados en el método, a un elemento de una colección que sea un atributo del objeto, y a un objeto devuelto por un método del objeto que invoca.

En ningún sitio se dice que esto sea fácil de conseguir, pero sin duda da lugar al desacoplamiento más adecuado para manejarse con sistemas que pueden cambiar constantemente.

Esto me lleva a apuntarme para próximos "posts" una explicación un poco más detallada de la Orientación a Aspectos. El curso pasado trajimos a un experto en AOP que ya explicó los fundamentos, pero vamos a ver si lo entendemos mejor.

Comments

Popular Posts