"Cadenas de mensajes" frente a "Hombre medio"

Question

Estoy leyendo el libro de refactorización de Fowler y estoy un poco confundido acerca de esos dos olores de código.

"Cadenas de mensajes" son llamadas como a.getB().getC().getValue().

"intermediario" es un método como

class A 
{ 
    object getCValue() 
    { 
     return b.getCValue(); 
    } 
} 

mi modo de entender los dos sección es que si tienes "Cadenas de mensajes" se les acorta mediante la introducción de "Middle Men". Y si tiene "Hombres medios", conviértalos en "Cadenas de mensajes" ...

Ahora, obviamente, tiene que haber alguna limitación en esto o tendría el tiovivo de un programador. ¿En qué punto debería favorecer uno sobre el otro?

Uno está acoplando la clase a clases no relacionadas, el otro está acoplando la clase a la estructura. Entonces, en teoría, mi enfoque sería verificar si un cambio determinado reduce un tipo de acoplamiento más de lo que aumenta el otro tipo de acoplamiento. Pero, ¿hay un tipo de acoplamiento peor y debería pesarse más? Es decir. ¿solo agrega un acoplamiento de clase si puede quitar los acoplamientos estructurales X?

Answer 1

Preferir intermediarios en cadenas de mensajes también se conoce como Law of Demeter, que se puede resumir como "solo hablar con sus dependencias directas".

Una de las ventajas del uso de intermediarios en lugar de cadenas de mensajes es que debe proporcionar menos simulaciones al realizar pruebas unitarias. Las clases se vuelven realmente difíciles de probar cuando debe proporcionar burlas no solo para sus dependencias directas sino también indirectas.

También ayuda a la separación de las preocupaciones, como el código que tiene un A y quiere un C no deberían tener que saber que hay un B involucrados. Esto ayuda a la modularidad.

El argumento principal para las cadenas de mensajes es que no tiene que escribir el texto estándar en el medio, y podría tener sentido en algunos casos, pero creo que la regla de oro debería ser preferir a los intermediarios.

Answer 2

Es su elección. Codifíquelo de la manera que crea que será más fácil de mantener. Por cierto, no creo que haya un caso de "acoplar la clase a clases no relacionadas". Más bien, se trata de convertir una relación indirecta en una relación directa. Esto es particularmente útil cuando accedes a la clase indirecta varias veces desde tu clase. Esto también podría eliminar algunas dependencias de las clases intermedias, según cómo establezca la relación directa.

Answer 3

Como dijo Hammar, este es todo acerca de la Ley de Demeter. Cosas como a.getB().getC().getD() son casi siempre malas. Introducen el acoplamiento al cliente de la interfaz A. Prefiere introducir un intermediario, como por ejemplo:

class A 
    def calculateHowManyCowsCanFitOnTheMoon 
     doLocalCalculation(b.performEncapsulatedCalculation()) 
    end 
end 

Usted quiere deshacerse de los intermediarios cuando no está sirviendo a un propósito como el de arriba, como cuando se acaba la extracción de datos a partir de B. Me gustaría ir en cuanto a decir que la refactorización para un mal hombre medio podría ser la refactorización Move Field/Move Method.