Origine de "une méthode doit renvoyer une valeur ou avoir des effets secondaires, mais pas les deux"

J'ai lu une fois qu'une méthode devrait avoir une valeur de retour (et être référentiellement transparente), ou avoir des effets secondaires, mais pas les deux. Je ne trouve aucune référence à cette règle, mais je souhaite en savoir plus.

Quelle est l'origine de ce conseil? De quelle personne ou communauté est-elle née?

Crédit supplémentaire: Quel est l'avantage revendiqué de suivre ces conseils?

Selon Greg Young, cette idée est née de Bertrand Meyer : séparation Command-Query .

Il indique que chaque méthode doit être soit une commande qui exécute une action, soit une requête qui renvoie des données à l'appelant, mais pas les deux. En d'autres termes, Poser une question ne devrait pas changer la réponse . ¹ Plus formellement, les méthodes ne devraient renvoyer une valeur que si elles sont référentiellement transparentes et ne présentent donc aucun effet secondaire.

1: Eiffel: un langage pour le génie logiciel slide 43-48

Dans la conception pilotée par domaine, cela est similaire à la séparation / séparation de commande-requête-lecture (CQRS), comme l'a nommé Greg Young.

Greg Young a repris l'idée de CQS de Bertrand pour nommer CQRS comme mentionné par Martin Fowler dans cet article du CQRS

Avantages

• La partie en lecture (requête) peut être mise à l'échelle / modifiée différemment de la partie en écriture (commande). Séparer les deux empêcherait l'un ou l'autre de se gêner lorsque l'optimisation / les performances sont essentielles.

Lisez l' article du lien Martin Fowler pour en savoir plus.

Je ne sais pas d'où cela vient, mais c'est un bon conseil et assez simple à comprendre.

Tout programme sainement conçu sera divisé en différentes parties, combinées et composées de différentes manières. Plus il est difficile de raisonner sur ce que fait une partie en particulier, plus il sera difficile de s'assurer que votre programme réagira de manière prévisible.

Isoler les parties qui produisent des effets secondaires facilite le raisonnement, le test et le débogage du reste. La réduction du nombre d'effets secondaires dans chaque partie qui génère un effet secondaire rendra cette partie plus facile à utiliser de la même manière.

Si vous le décomposez encore plus, une valeur de retour est un effet. Les effets secondaires sont un effet. Une fonction ne devrait produire qu'un seul effet (si possible), car plus un nombre d'entrées et d'effets est important, plus il est difficile de raisonner sur ce qu'elle fait réellement.

Crédit supplémentaire: Quel est l' avantage initialement revendiqué de suivre ces conseils?

L'un des avantages de la séparation de la valeur de retour des effets secondaires est qu'elle élimine un problème potentiel qui peut être causé par une évaluation de court-circuit .

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
}