Devo scendere a compromessi: DRY o Command-Query-Separation?

Recentemente ho refactoring un metodo che era sia un comando che un metodo di query.

Dopo averlo separato in un metodo a un comando e un metodo di query, ho scoperto che ora ci sono più posizioni nel codice in cui sto chiamando il comando per ottenere il valore dalla query, che sembra una violazione del principio DRY.

Ma se dovessi racchiudere quel codice comune in un metodo, quel metodo sarebbe sia il comando che una query. È accettabile?

Ci sono sempre compromessi da considerare tra principi progettuali contrastanti. Il modo per risolverlo è quello di esaminare le ragioni alla base dei principi. In questo caso, non essere in grado di eseguire una query senza eseguire il comando è problematico, ma essere in grado di eseguire un comando senza eseguire la query è generalmente innocuo. Finché esiste un modo per eseguire la query autonomamente, non vedo alcun motivo per non aggiungere il risultato della query al comando, soprattutto se fatto qualcosa del genere:

QueryResult command()
{
   // do command stuff
   return query();
}

Non ho mai sentito parlare di Command-Query-Separation (CQS) prima, ma sembra che si riferirebbe al Single Responsibility Principle (SRP), che afferma che una funzione / classe dovrebbe idealmente essere responsabile di fare una cosa e una cosa sola .

Se il tuo codice di comando è di 20 righe di codice e il codice di query è di altre 30 righe e sono tutte in un corpo di funzione, chiaramente stai violando SRP e suppongo che anche CQS e quei due pezzi di logica dovrebbero essere separati l'uno dall'altro .

Tuttavia, andando con il tuo esempio ipotetico, molto probabilmente creerei un metodo wrapper che combina il comando e la query in modo che DRY non venga violato in numerosi punti del codice. Inoltre, non lo considero una violazione di SRP (e forse CQS), poiché il wrapper ha ancora una sola responsabilità: combinare il comando con una query e creare un'astrazione di livello superiore più facile da consumare.

Penso che il metodo wrapper sia una soluzione perfettamente accettabile e per illustrarlo, facciamo un passo avanti nel tuo esempio. E se fosse necessario eseguire 2 query anziché 1 e quindi eseguire un'azione di comando basata su quella. Quindi le tue 2 righe di codice sarebbero 6 o 8. E se ci fosse qualche validazione / verifica dei dati tra l'una e l'altra, quindi ora hai 15 righe di codice. Ci penseresti due volte sulla creazione di un wrapper che fa tutto questo, piuttosto che cospargere quelle 15 righe in più file?

L'ASCIUGATURA è più importante, poiché risolve un'esigenza molto più fondamentale, evitando sforzi ridondanti ed effettivamente sprecati. Questa è una cosa fondamentale: non è necessario essere programmatori per capirlo.

CQS è una risposta alla difficoltà, in lingue senza supporto per gli effetti di tracciamento, di comprendere il codice che viene eseguito sia per i suoi risultati che per i suoi effetti. Però:

1. La necessità di eseguire il codice per i suoi risultati non può essere evitata, poiché questa è la base per comporre grandi programmi da piccole unità.

2. La necessità di eseguire il codice per i suoi effetti non può essere evitata, perché, al di fuori della matematica e dell'informatica teorica, il valore dell'esecuzione di un programma risiede su ciò che osservabilmente può fare per noi.

3. La necessità di causare effetti e produrre risultati nello stesso codice non può essere evitata, perché, in pratica, abbiamo bisogno sia di effetti che di composizionalità, non solo l'uno o l'altro.

La vera soluzione al problema di tenere traccia degli effetti troppo difficili per gli esseri umani senza aiuto è, ovviamente, che i computer ci aiutino ! Una cosa simile si può dire sul tracciamento di relazioni complesse tra i valori di runtime (come la validità degli indici di array), per i quali eccezioni e contratti applicati dal runtime costituiscono (non) soluzioni.

In conclusione, "soluzioni" come CQS si limitano semplicemente a progettare programmi secondo solidi principi basati sulla realtà. Vai a SECCO.