¿Es un código como este un "choque de trenes" (en violación de la Ley de Demeter)?

Al navegar por el código que he escrito, me encontré con la siguiente construcción que me hizo pensar. A primera vista, parece lo suficientemente limpio. Sí, en el código real, el getLocation()método tiene un nombre un poco más específico que describe mejor exactamente qué ubicación se obtiene.

service.setLocation(this.configuration.getLocation().toString());

En este caso, servicees una variable de instancia de un tipo conocido, declarada dentro del método. this.configurationproviene de ser pasado al constructor de la clase, y es una instancia de una clase que implementa una interfaz específica (que exige un getLocation()método público ). Por lo tanto, this.configuration.getLocation()se conoce el tipo de retorno de la expresión ; específicamente en este caso, es un java.net.URL, mientras que service.setLocation()quiere un String. Dado que los dos tipos String y URL no son directamente compatibles, se requiere algún tipo de conversión para ajustar la clavija cuadrada en el agujero redondo.

Sin embargo , de acuerdo con la Ley de Demeter como se cita en código limpio , un método de f en la clase C sólo debe llamar a métodos en C , los objetos creados por o pasado como argumentos a f , y objetos celebrada en variables de instancia de C . Cualquier cosa más allá de eso (la final toString()en mi caso particular anterior, a menos que considere un objeto temporal creado como resultado de la invocación del método en sí, en cuyo caso toda la Ley parece ser discutible) no está permitido.

¿Existe un razonamiento válido por el cual una llamada como la anterior, dadas las restricciones enumeradas, debe ser desalentada o incluso rechazada? ¿O solo estoy siendo demasiado quisquilloso?

Si tuviera que implementar un método URLToString()que simplemente llama toString()a un URLobjeto (como el devuelto por getLocation()) pasado como parámetro y devuelve el resultado, podría ajustar la getLocation()llamada para lograr exactamente el mismo resultado; efectivamente, solo movería la conversión un paso hacia afuera. ¿Eso de alguna manera lo haría aceptable? (Me parece , intuitivamente, que no debería hacer ninguna diferencia de ninguna manera, ya que todo lo que hace es mover un poco las cosas. Sin embargo, siguiendo la letra de la Ley de Deméter como se citó, sería aceptable, ya que yo entonces estaría operando directamente en un parámetro a una función).

¿Habría alguna diferencia si se tratara de algo un poco más exótico que recurrir toString()a un tipo estándar?

Al responder, tenga en cuenta que alterar el comportamiento o la API del tipo de la servicevariable no es práctico. Además, en aras de la discusión, digamos que alterar el tipo de retorno de getLocation()tampoco es práctico.

El problema aquí es la firma de setLocation. Está mecanografiado en cadena .

Para elaborar: ¿Por qué esperaría String? A Stringrepresenta cualquier tipo de datos textuales . Potencialmente puede ser cualquier cosa menos una ubicación válida.

De hecho, esto plantea una pregunta: ¿qué es una ubicación? ¿Cómo yo sé sin mirar en su código? Si fuera un URL, sabría mucho más sobre lo que este método espera.
Tal vez tendría más sentido que fuera una clase personalizada Location. Ok, al principio no sabría qué es eso, pero en algún momento (probablemente antes de escribir this.configuration.getLocation()me tomaría un minuto para descubrir qué es lo que devuelve este método).
De acuerdo, en ambos casos necesito buscar otro lugar para entender lo que se espera. Sin embargo, en el último caso, si entiendo, qué Locationes, puedo usar su API, en el primer caso, si entiendo, qué Stringes (lo que se puede esperar), todavía no sé qué espera su API.

En el escenario poco probable, que una ubicación es cualquier tipo de datos textuales , reinterpretaría esto a cualquier tipo de datos que tengan una representación textual . Dado el hecho de que Objecttiene un toStringmétodo, podría ir con eso, aunque esto exige un gran salto de fe de los clientes de su código.

También debe considerar que está hablando de Java, que tiene muy pocas características por diseño. Eso es lo que te obliga a llamar toStringal final.
Si toma C #, por ejemplo, que también está estáticamente tipado, entonces podría omitir esa llamada definiendo el comportamiento para una conversión implícita .
En lenguajes de tipo dinámico, como Objective-C, tampoco necesita la conversión, porque siempre que el valor se comporte como una cadena, todos estarán contentos.

Se podría argumentar que la última llamada a toStringes menos una llamada, que en realidad solo ruido generado por la demanda de explicidad de Java. Está llamando a un método que tiene cualquier objeto Java, por lo tanto, en realidad no codifica ningún conocimiento sobre una "unidad distante" y, por lo tanto, no viola el Principio de Menos Conocimiento. No hay forma, no importa lo que getLocationregrese, de que no tenga un toStringmétodo.

Pero, por favor, no use cadenas, a menos que sean realmente la opción más natural (o a menos que esté usando un lenguaje, que ni siquiera tiene enumeraciones ... estado allí).

La ley de Demeter es una directriz de diseño, no una ley a seguir religiosamente.

Si cree que sus clases están lo suficientemente desacopladas, no hay nada de malo en la línea, this.configuration.getLocation()especialmente si, como usted dice, no es práctico cambiar otras partes de la API.

Estoy bastante seguro de que el cliente estará perfectamente feliz incluso si hace la Ley de Demeter en pedazos, siempre que entregue lo que quiere y a tiempo. Lo cual no es una excusa para crear un mal software, sino un recordatorio para ser pragmático al desarrollar software.

Lo único que se me ocurre al no escribir código como este es ¿qué pasa si this.configuration.getLocation()devuelve nulo? Depende de su código circundante y del público objetivo que usa este código. Pero como dice Marco, la ley de Demeter es una regla general, es bueno seguirla, pero no te rompas la espalda innecesariamente.

Seguir estrictamente la Ley de Demeter significaría que debe implementar un método en el objeto de configuración como:

function getLocationAsString() {
  return getLocation().toString();
}

pero personalmente no me molestaría porque esta es una situación tan pequeña, y de todos modos tus manos están un poco atadas debido a la API que no puedes cambiar. Las reglas de programación son sobre lo que debe hacer cuando tiene una opción, pero a veces no tiene otra opción.