if-else書くことができ、複数のハンドラーを通過する代わりに、必要なハンドラーを見つけて、特定のハンドラーに処理を委任できるのに、なぜ CoR を使用する必要があるのか。
CoR は、複数のハンドラーで同じリクエストを処理するためのパイプラインとして使用されていないと思います (このように: https://github.com/RichJones22/chainOfResponsibility_cpp/blob/master/main.cpp )。では、なぜ CoR を使用するのでしょうか。
CoRの利点は何ですか？
これは一種のパイプラインであることは間違いありません。パイプラインの各ステップは、基本クラス インターフェイスを介して次のステップとやり取りします。パイプラインの各ステップが前のステップのコンテキストに直接依存していないか、関連している場合に使用できます。
各クラスは、パイプラインの独自のステージを実装します。利点は次のとおりです。
モジュール化: 各パイプライン クラスは、明確に定義された側面/コマンドを扱います。各コマンド オブジェクト/パイプライン ステージのコードは、よりクリーンで読み取り/保守が容易になるはずです。
1 つの利点は、残りのコマンド/パイプライン クラスから独立して、これらの各クラスを個別にデバッグ/テストできることです。単体テストがある場合、これは素晴らしいことです。
ファクトリ/ビルダー クラスでパイプラインのさまざまなインスタンスを構成し、コマンド クラスをビルディング ブロックとして扱い、構成/実際の要件に応じてそれらを積み重ねることができます。
一例はロギング段階です。ログを記録するだけの派生クラスを追加し、それをパイプラインの最後に追加します。イベントをログに記録する必要があります。「ログなしモード構成」の場合、このコマンド オブジェクトはスタックされません。
チェーン内の 10 要素のうち 4 つを実行する必要がある場合、別の場合は 2 つ、別の場合は 9 つを実行する必要がある場合、ネストされた多数の if ステートメントよりも CoR の方が明らかに優れています。
一連のバリデーターなどの従来の実装を検討してください。特定のケースでいくつかのバリデーターをプラグインおよびアウトしたり、最初の検証エラーで失敗したり、すべてを収集したりすることができます。