Come scegliere tra Tell not Ask e Command Query Separation?

Il principio Tell Don't Ask dice:

dovresti cercare di dire agli oggetti cosa vuoi che facciano; non porre loro domande sul loro stato, prendere una decisione e poi dire loro cosa fare.

Il problema è che, come chiamante, non dovresti prendere decisioni basate sullo stato dell'oggetto chiamato che ti porta a cambiare lo stato dell'oggetto. La logica che stai implementando è probabilmente la responsabilità dell'oggetto chiamato, non la tua. Per te prendere decisioni al di fuori dell'oggetto viola la sua incapsulamento.

Un semplice esempio di "Tell, Don't Ask" è

Widget w = ...;
if (w.getParent() != null) {
  Panel parent = w.getParent();
  parent.remove(w);
}

e la versione tell è ...

Widget w = ...;
w.removeFromParent();

E se avessi bisogno di sapere il risultato dal metodo removeFromParent? La mia prima reazione è stata solo quella di cambiare removeFromParent per restituire un valore booleano che indica se il genitore è stato rimosso o meno.

Ma poi mi sono imbattuto in un modello di separazione delle query di comando che dice di NON farlo.

Indica che ogni metodo dovrebbe essere un comando che esegue un'azione o una query che restituisce dati al chiamante, ma non entrambi. In altre parole, porre una domanda non dovrebbe cambiare la risposta. Più formalmente, i metodi dovrebbero restituire un valore solo se sono referenzialmente trasparenti e quindi non presentano effetti collaterali.

Questi due sono davvero in contrasto tra loro e come faccio a scegliere tra i due? Vado con il programmatore pragmatico o Bertrand Meyer su questo?

In realtà il tuo problema di esempio illustra già la mancanza di decomposizione.

Cambiamolo un po ':

Book b = ...;
if (b.getShelf() != null) 
    b.getShelf().remove(b);

Questo non è molto diverso, ma rende più evidente il difetto: perché il libro dovrebbe sapere del suo scaffale? In poche parole, non dovrebbe. Introduce una dipendenza di libri sugli scaffali (che non ha senso) e crea riferimenti circolari. Va tutto male.

Allo stesso modo non è necessario che un widget conosca il suo genitore. Dirai: "Ok, ma il widget ha bisogno del suo genitore per impaginarsi correttamente ecc." e sotto il cofano il widget conosce il suo genitore e gli chiede le sue metriche per calcolare le proprie metriche basate su di esse, ecc. Secondo quanto detto, non chiedere che sia sbagliato. Il genitore dovrebbe dire a tutti i suoi figli di renderizzare, passando tutte le informazioni necessarie come argomenti. In questo modo si può facilmente avere lo stesso widget in due genitori (indipendentemente dal fatto che ciò abbia effettivamente senso).

Per tornare all'esempio del libro, inserisci il bibliotecario:

Librarian l = ...;
Book b = ...;
l.findShelf(b).remove(b);

Per favore, capisci che non stiamo più chiedendo nel senso di dire, non chiedere .

Nella prima versione, lo scaffale era una proprietà del libro e tu l'hai chiesto. Nella seconda versione, non facciamo simili ipotesi sul libro. Tutto ciò che sappiamo è che il bibliotecario può dirci uno scaffale che contiene il libro. Presumibilmente si affida a una sorta di tabella di ricerca per farlo, ma non lo sappiamo per certo (potrebbe anche scorrere tutti i libri in ogni scaffale) e in realtà non vogliamo saperlo .
Non facciamo affidamento sul fatto se o come la risposta dei bibliotecari sia accoppiata al suo stato o a quello di altri oggetti da cui potrebbe dipendere. Diciamo al bibliotecario di trovare lo scaffale.
Nel primo scenario, abbiamo codificato direttamente la relazione tra un libro e uno scaffale come parte dello stato del libro e recuperato direttamente questo stato. Questo è molto fragile, perché ipotizziamo anche che lo scaffale restituito dal libro contenga il libro (questo è un vincolo che dobbiamo garantire, altrimenti potremmo non essere in grado di leggere removeil libro dallo scaffale in cui si trova effettivamente).

Con l'introduzione del bibliotecario, modelliamo questa relazione separatamente, ottenendo quindi la separazione delle preoccupazioni.

Se hai bisogno di conoscere il risultato, allora lo fai; questo è il tuo requisito.

La frase "i metodi dovrebbero restituire un valore solo se sono referenzialmente trasparenti e quindi non hanno effetti collaterali" è una buona linea guida da seguire (soprattutto se stai scrivendo il tuo programma in uno stile funzionale , per concorrenza o altri motivi), ma è non un assoluto.

Ad esempio, potrebbe essere necessario conoscere il risultato di un'operazione di scrittura del file (vero o falso). Questo è un esempio di un metodo che restituisce un valore, ma produce sempre effetti collaterali; non c'è modo di aggirare questo.

Per soddisfare la separazione di comandi / query, è necessario eseguire l'operazione sul file con un metodo, quindi verificarne il risultato con un altro metodo, una tecnica indesiderabile perché disaccoppia il risultato dal metodo che ha causato il risultato. Cosa succede se succede qualcosa allo stato dell'oggetto tra la chiamata al file e il controllo dello stato?

La linea di fondo è questa: se stai usando il risultato di una chiamata di metodo per prendere decisioni altrove nel programma, allora non stai violando Tell Don't Ask. Se, d'altra parte, stai prendendo decisioni per un oggetto basato su una chiamata del metodo a quell'oggetto, allora dovresti spostare quelle decisioni nell'oggetto stesso per preservare l'incapsulamento.

Ciò non è affatto contraddittorio con la separazione delle query di comando; in effetti, lo impone ulteriormente, perché non è più necessario esporre un metodo esterno a fini di stato.

Penso che dovresti seguire il tuo istinto iniziale. A volte il design dovrebbe essere intenzionalmente pericoloso, per introdurre immediatamente complessità quando si comunica con l'oggetto in modo che il tuo forzato lo maneggi correttamente subito, invece di provare a gestirlo sull'oggetto stesso e nascondere tutti i dettagli cruenti e renderlo difficile da pulire cambiare le ipotesi sottostanti.

Dovresti avere una sensazione di affondamento se un oggetto ti offre equivalenti opene closecomportamenti implementati e inizi immediatamente a capire con cosa hai a che fare quando vedi un valore di ritorno booleano per qualcosa che ritieni possa essere un semplice compito atomico.

Come ti occuperai in seguito è la tua passione. Puoi creare un'astrazione sopra di esso, un tipo di widget con removeFromParent(), ma dovresti sempre avere un fallback di basso livello, altrimenti potresti aver fatto ipotesi premature.

Non provare a rendere tutto semplice. Non c'è nulla di così deludente quando ti affidi a qualcosa che sembra elegante e così innocente, solo per rendersi conto che è vero orrore in seguito nei momenti peggiori.

Ciò che descrivi è una "eccezione" nota al principio di separazione comando-query.

In questo articolo Martin Fowler spiega come minaccerebbe tale eccezione.

A Meyer piace usare assolutamente la separazione comando-query, ma ci sono eccezioni. Il blocco di uno stack è un buon esempio di query che modifica lo stato. Meyer afferma correttamente che puoi evitare di avere questo metodo, ma è un linguaggio utile. Quindi preferisco seguire questo principio quando posso, ma sono pronto a romperlo per ottenere il mio pop.

Nel tuo esempio considererei la stessa eccezione.

La separazione comandi-query è incredibilmente facile da fraintendere.

Se ti dico nel mio sistema c'è un comando che restituisce anche un valore da una query e dici "Ah! Sei in violazione!" stai saltando la pistola.

No, non è ciò che è proibito.

Ciò che è proibito è quando quel comando è l'UNICO modo per fare quella query. No. Non dovrei cambiare stato per porre domande. Ciò non significa che devo chiudere gli occhi ogni volta che cambio stato.

Non importa se lo faccio poiché li riaprirò comunque. L'unico vantaggio di questa reazione eccessiva è stato garantire che i progettisti non diventassero pigri e dimenticassero di includere la query che modifica lo stato.

Il vero significato è così dannatamente sottile che per i pigri è più facile dire che i setter dovrebbero tornare vuoti. Questo rende più facile essere sicuri di non violare la vera regola, ma è una reazione eccessiva che può diventare un vero dolore.

Le interfacce fluide e iDSL "violano" continuamente questa reazione eccessiva. C'è molto potere che viene ignorato se si reagisce in modo eccessivo.

Si può sostenere che un comando dovrebbe fare solo una cosa e una query dovrebbe fare solo una cosa. E in molti casi questo è un buon punto. Chi può dire che esiste una sola query che dovrebbe seguire un comando? Bene, ma non si tratta di separazione query-comando. Questo è il principio della singola responsabilità.

Guardato in questo modo e uno stack pop non è un'eccezione bizzarra. È una singola responsabilità. Pop viola la separazione delle query di comando solo se si dimentica di fornire una sbirciatina.