「メソッドは値を返すか副作用があるはずですが、両方ではありません」の起源

私は一度、メソッドには戻り値があり（参照的に透過的）、または副作用がありますが、両方ではないことを読みました。このルールへの参照は見つかりませんが、それについてもっと学びたいです。

このアドバイスの起源は何ですか？どの人またはコミュニティからそれが生じましたか？

追加クレジット：このアドバイスに従うことの利点は何ですか？

グレッグヤングによると、このアイデアはBertrand Meyerから生まれました：コマンドとクエリの分離。

すべてのメソッドは、アクションを実行するコマンド、または呼び出し元にデータを返すクエリのいずれかである必要がありますが、両方ではないことを示しています。言い換えれば、質問をすることで答えが変わることはありません。¹ より正式には、メソッドは参照的に透明であり、したがって副作用がない場合にのみ値を返す必要があります。

1：Eiffel：ソフトウェアエンジニアリングスライド43-48の言語

ドメインドリブンデザインでは、これはグレッグヤングによって命名されたコマンド-クエリ-読み取り分離/分離（CQRS）に似ています。

このCQRS記事でMartin Fowlerが言及したように、グレッグヤングはバートランドのCQSのアイデアを取り入れてCQRSを命名しました。

利点

• 読み取り（クエリ）部分は、書き込み（コマンド）部分とは異なる方法でスケーリング/微調整できます。2つを分離すると、最適化/パフォーマンスが重要な場合に、どちらかが互いに邪魔になるのを防ぐことができます。

詳細については、Martin Fowlerリンクの記事を参照してください。

どこから来たのかわかりませんが、良いアドバイスであり、理解するのはかなり簡単です。

適切に設計されたプログラムは、さまざまな部分に分割され、さまざまな方法で結合および構成されます。特定の部分が何をするのかを推論するのが難しいほど、プログラムが予測可能な方法で反応することを確認するのが難しくなります。

副作用を引き起こす部分を分離することで、残りの部分の推論、テスト、デバッグが容易になります。副作用を生成する各部品の副作用の数を減らすと、同じ方法でその部品を操作しやすくなります。

さらに分解すると、戻り値が効果になります。副作用は効果です。関数が持つ入力と効果の数が多いほど、実際に何をするのかを推論するのが難しくなるため、関数は1つの効果（可能な場合）のみを生成します。

追加クレジット：このアドバイスに従うことで最初に主張される利点は何ですか？

戻り値を副作用から分離することの利点の1つは、短絡評価によって引き起こされる可能性のある潜在的な問題を取り除くことです。

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
}