Please enable JavaScript.
Coggle requires JavaScript to display documents.
Ley de Demeter: No aceptes caramelos de desconocidos Dulces-golosina-…
Ley de Demeter: No aceptes caramelos de desconocidos
La problemática
Todo bien:
Estamos creando nuestro código a partir de clases pequeñas que interactúan entre ellas
Empiezan los problemas:
Una de las clases necesita utilizar alguno
de los objetos unos cuantos niveles por debajo
Creamos getters como si no hubiera un mañana
¿Cuál es el problema aquí?
Estamos acoplando el código a la estructura de las clases que componen la cadena de llamadas
Si mañana se cambia esa estructura en cualquiera de las clases involucradas, el código se
ve afectado
El código queda muy
propenso a modificaciones
¿Qué es la Ley de Demeter?
Un mecanismo de detección de acoplamiento
Nos avisa que nuestro objeto no debería conocer las entrañas de otros objetos con los que interactúa
Se detecta cuando
Nos encontramos con muchas
llamadas concatenadas
Si accedes a la estructura interna de otra clase para llamara a sus métodos
Se cumple cuando
Para un función f de una clase C
Sólo llama a funciones de
C
Un objecto creado por
Un objeto pasado como argumento a f
Un objeto almacenado en campo de C
Un elegante encapsulamiento de clases es arruinado cuando lo llenas todo de getters
¿Cómo soluciono las violaciones de la Ley de Demeter?
Añadir métodos extra
Esta es la opción más evidente, y la menos recomendada
Normalmente lo que está haciendo
es esconder el problema, no solucionarlo
Arquitectura
Una buena arquitectura reduce bastante la posibilidad de violar esta ley
Cada capa tendrá una serie de interfaces con las que comunicarse
Estas ocultaran su información
Comprender mejor tu dominio
Domain Driven Design
Nuestro
problema se puede sustentar en unos conceptos clave que lo definen
Todo el proceso de desarrollo se simplifica mucho
Se hace hincapié en los distintos tipos de elementos
que nos pueden ayudar a modelar nuestro software
No hay una
solución única
Depende del tipo de clase que tengamos
Objetos
Definen
comportamiento
Les pedimos que
hagan cosas
Estructuras de datos
Almacenan estado
Les pedimos que nos den cosas
La aplicación de esta ley pierde validez
Conclusión
No tomársela como algo que no nos podemos saltar
Siempre que algo huela mal es probable que haya una forma más elegante de hacerlo
La sobre-ingeniería es tan mala como la completa carencia de
ella
