Origine di "un metodo dovrebbe restituire un valore o avere effetti collaterali, ma non entrambi"

Ho letto una volta che un metodo dovrebbe avere un valore di ritorno (ed essere referenzialmente trasparente), oppure avere effetti collaterali, ma non entrambi. Non riesco a trovare riferimenti a questa regola, ma voglio saperne di più.

Qual è l'origine di questo consiglio? Da quale persona o comunità è nata?

Credito extra: qual è il vantaggio dichiarato di seguire questo consiglio?

Secondo Greg Young, questa idea è nata da Bertrand Meyer : separazione Command-Query .

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, fare 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.

1: Eiffel: un linguaggio per l'ingegneria del software slide 43-48

In Domain Driven Design, questo è simile a Command-Query-Read Separation / Segregation (CQRS), come nominato da Greg Young.

Greg Young ha preso l'idea di CQS da Bertrand per nominare CQRS come menzionato da Martin Fowler in questo articolo CQRS

Benefici

• La parte di lettura (query) può essere ridimensionata / ottimizzata in modo diverso dalla parte di scrittura (comando). Separare i due impedirebbe l'uno o l'altro di intralciarsi quando l'ottimizzazione / le prestazioni sono fondamentali.

Leggi l' articolo nel link Martin Fowler per ulteriori informazioni.

Non so da dove venga, ma è un buon consiglio e abbastanza chiaro da capire.

Qualsiasi programma progettato in modo sano verrà suddiviso in varie parti, combinate e composte in vari modi. Più è difficile ragionare su ciò che fa una parte particolare, più sarà difficile assicurarsi che il programma reagisca in modo prevedibile.

L'isolamento delle parti che producono effetti collaterali rende il resto più facile da ragionare, testare ed eseguire il debug. Ridurre il numero di effetti collaterali in ogni parte che genera un effetto collaterale renderà più facile lavorare quella parte nello stesso modo.

Se lo decomponi ulteriormente, un valore restituito è un effetto. Gli effetti collaterali sono un effetto. Una funzione dovrebbe produrre solo 1 effetto (se possibile) perché maggiore è il numero di input ed effetti di una funzione, maggiore è la difficoltà nel ragionare su ciò che effettivamente fa.

Credito extra: qual è il vantaggio inizialmente dichiarato di seguire questo consiglio?

Uno dei vantaggi della separazione del valore di ritorno dagli effetti collaterali è che rimuove un potenziale problema che può essere causato dalla valutazione del corto circuito .

bool FooWithSideEffect() {
    // do query
    // do side effect
    return resultOfQuery;
}

bool BarWithSideEffect() {
    // do query
    // do side effect
    return resultOfQuery;
}

void BadShortCircuitEvaluation()
{
    // the programmer's intent is to have side effects of both functions
    if (FooWithSideEffect() && BarWithSideEffect() ) {
        // do something
    }

    // in case FooWithSideEffect() returns true, 
    // then BarWithSideEffect() is not called at all
    // because of short-circuit evaluation
}