Please enable JavaScript.
Coggle requires JavaScript to display documents.
LEY DE DEMETER: No aceptes caramelos de desconocidos ley-de-demeter-no…
LEY DE DEMETER:
No aceptes caramelos de desconocidos
¿Qué es la Ley de Demeter?
Es un mecanismo de detección de acoplamiento
nos viene a decir que nuestro objeto no debería conocer las entrañas de otros objetos con los que interactúa.
Una forma fácil de detectar que se está violando esta Ley es encontrarte con muchas
llamadas concatenadas
Si estás accediendo a la estructura
interna de otra clase para llamar a sus métodos, seguramente estés violando la ley.
se cumple la ley cuando:
Teniendo una función f de una clase C, esa función sólo llama a funciones de:
C
Un objeto creado por f
Un objeto pasado como argumento a f
Un objeto almacenado en campo de C
¿Cuál es el problema aquí?
Que estamos acoplando el código a la estructura de las clases que componen la cadena de llamadas.
Si mañana cambia esa estructura en cualquiera de las clases involucradas, este código se ve afectado.
¿Es esto malo?
en general sí, porque este código es muy
propenso a modificaciones
El código no está bien hecho
La problemática
Estamos creando nuestro código a partir
de clases pequeñas que interactúan entre ellas
Es normal en orientación a objetos
Está muy bien, el problema surge cuando:
una de las clases necesita utilizar alguno
de los objetos unos cuantos niveles por debajo.
nos dedicamos a crear getters como si no hubiera un mañana.
Puede ser peligroso
¿Cómo soluciono las violaciones de la Ley de Demeter?
No hay una solución única
Depende del tipo de clase que tengamos
Objetos
es normal pedirles que hagan cosas
Definen comportamiento
Estructuras de Datos
es más habitual pedirles que nos den cosas.
Almacenan estado.
Opciones:
Añadir métodos extra
Esta es la opción más evidente, y la que menos te recomiendo.
En algún caso puede valer, pero normalmente lo que está haciendo es esconder el problema
Arquitectura
Una buena arquitectura juega un papel muy importante en el desacoplamiento de los distintos módulos del software
Reducirá bastante la posibilidad de violar esta ley.
Cada capa tendrá una serie de interfaces con las que comunicarse
esas capas ocultarán su implementación
Comprender mejor tu dominio
Domain Driven Design
Hace mucho hincapié en los distintos tipos de elementos que nos pueden ayudar a modelar nuestro software
Nuestro problema se puede sustentar en unos conceptos clave que lo definen
teniéndolos muy claros todo el proceso de desarrollo se simplifica mucho.
Conclusiones
La sobre-ingeniería es tan mala como la completa carencia de ella.
No tomársela como algo que no nos podemos saltar
