Il codice è simile a un "naufragio del treno" (in violazione della legge di Demeter)?

Il problema qui è la firma di setLocation . È digitato in modo stringato .

Per elaborare: Perché dovrebbe aspettarsi String ? Un String rappresenta qualsiasi tipo di dati testuali . Può potenzialmente essere tutto tranne che una posizione valida.

In realtà, questo pone una domanda: che cos'è una posizione? Come si sa I senza guardare nel codice? Se fosse un URL di quanto ne saprei molto di più su ciò che questo metodo si aspetta.
Forse avrebbe più senso che fosse una classe personalizzata Location . Ok, non lo saprei all'inizio, che cos'è, ma ad un certo punto (probabilmente prima di scrivere this.configuration.getLocation() vorrei prendere un minuto per capire di cosa tratta questo metodo).
Certo, in entrambi i casi ho bisogno di cercare un altro posto per capire, cosa è previsto. Tuttavia, nel secondo caso, se capisco, che cos'è Location , posso usare la tua API, nel primo caso, se ho capito, che cos'è String (che può essere previsto), non lo faccio ancora sapere cosa si aspetta la tua API.

Nello scenario improbabile, che una posizione sia qualsiasi tipo di dati testuali la reinterpreterei a qualsiasi tipo di dati, che ha una rappresentazione testuale . Dato che Object ha un metodo toString , potresti andare con quello, sebbene ciò richieda un vero e proprio sfiducia dai client del tuo codice.

Dovresti anche considerare che stai parlando di Java, che ha pochissime funzionalità di design. Questo è ciò che ti costringe a chiamare effettivamente toString alla fine.
Se prendi C # per esempio, che è anche tipizzato staticamente, allora potresti effettivamente omettere quella chiamata da definizione del comportamento per un cast implicito .
In linguaggi tipizzati dinamicamente, come Objective-C, non hai nemmeno bisogno della conversione, perché finché il valore si comporta come una stringa, tutti sono felici.

Si potrebbe obiettare che l'ultima chiamata a toString è meno una chiamata, piuttosto che solo il rumore generato dalla richiesta di Java di esplicitezza. Stai chiamando un metodo, che ha qualsiasi oggetto Java, quindi non codifichi effettivamente alcuna conoscenza su una "unità distante" e quindi non violi il Principio della Minima Conoscenza. Non c'è modo, a prescindere da cosa restituisca getLocation , che non abbia un metodo toString .

Ma per favore, non usare le stringhe, a meno che non siano davvero la scelta più naturale (o a meno che tu non stia usando una lingua, che non abbia nemmeno enumerazioni ... lì).

La legge di Demeter è una linea guida del design, non una legge da seguire religiosamente.

Se ritieni che le tue classi siano abbastanza disgiunte che non c'è nulla di sbagliato nella riga this.configuration.getLocation() , specialmente se, come dici tu, non è pratico modificare altre parti dell'API.

Sono abbastanza sicuro che il cliente sarà perfettamente felice anche se farai a pezzi la legge di Demeter, purché tu rispetti ciò che vuole e in tempo. Quale non è una scusa per fare software cattivo, ma un promemoria per essere pragmatico nello sviluppo del software.

L'unica cosa che posso pensare di non scrivere codice come questo è cosa succede se this.configuration.getLocation() restituisce null? Dipende dal codice circostante e dal pubblico di destinazione che utilizza questo codice. Ma come dice Marco - la legge di Demeter è una regola empirica - è bello seguire, ma non spezzarti le spalle senza farlo troppo.

Seguire rigorosamente la legge di Demeter significherebbe che dovresti implementare un metodo nell'oggetto di configurazione come:

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

ma personalmente non mi preoccuperei perché questa è una situazione così piccola, e comunque le tue mani sono un po 'legate a causa dell'API che non puoi cambiare. Le regole di programmazione riguardano ciò che dovresti fare quando hai una scelta, ma a volte non hai scelta.