【チェーン・オブ・レスポンシビリティパターン】
Chain of Responsibilityパターン とは？
最終更新:
💡 処理するか次へ渡すかを、連鎖で判断する
要求を複数の処理者へ順に渡し、処理するか次へ渡すかを各処理者が判断する設計パターン。処理の停止、順序、未処理の場合、ミドルウェアとの違いを解説します。
📌 このページのポイント
- 送り手が具体的な処理者を直接選ばず、連鎖へ要求を渡す
- 各処理者が、担当するか次へ渡すかを判断する
- 順序と停止条件を明示する。全処理者が必ず動くわけではない
- 処理者の追加にも実装・構成・テストが必要
ひよこ 責任の連鎖って、たらい回しのこと？
ペンギン先生 ここでは設計パターンの名前だよ。要求を複数の処理者につなぎ、各処理者が担当するか次へ渡すかを判断する。送り手が、具体的に誰へ頼むかを細かく知る必要を減らすんだ。
ひよこ どんな場面を考えると分かりやすい？
ペンギン先生 ヘルプ要求の例なら、現在の画面で説明できればそこで処理し、説明できなければ親の画面や全体の窓口へ渡す、という連鎖を作れるよ。この例では、担当したところで止めるんだ。
ひよこ 認証とログ記録を順番にするのも、同じ？
ペンギン先生 似た構成にできるけれど、動きは設計によるよ。各処理が仕事をした後で次へ進むものも、処理を引き受けたら止まるものもある。「必ず最初の一つだけ」「必ず全員が処理する」のどちらにも固定しないようにしよう。
ひよこ 処理者を追加すれば、既存コードの修正は不要？
ペンギン先生 送り手への影響を減らせることはあるよ。ただし追加する処理者の実装や、連鎖の構成、順序、テストは必要だ。特定の実装では実行後に構成を変更できないこともある。何も変えず自動で追加できる保証ではないんだ。
ひよこ 誰も処理できなかったら、必ずエラーになる？
ペンギン先生 未処理を返す、既定の処理者を用意する、例外にするなど、アプリの方針で決めるよ。順序によって結果が変わることもあるので、成功だけでなく、途中で止まる場合や末尾まで到達する場合も確認しよう。
もっと詳しく知りたい人へ
チェーンと、すべての工程を通るパイプラインは同じ？
見た目が似ていても、停止条件や要求の扱いが異なります。パイプラインは段階ごとの変換を中心に説明することが多く、責任連鎖では処理者の選択や委譲が重要です。名前だけで判断せず、何を渡し、どこで止める設計かを確認します。
戻り値がtrueなら、どの実装でも成功？
戻り値の意味は共通の法則ではありません。Apache Commons Chainのexecuteではtrueはチェーンの処理完了、falseは継続を表します。業務上の成功・失敗とは別に定めることもできるので、使うインターフェースの契約を確認します。
まとめ：ざっくりこれだけ覚えればOK！
「Chain of Responsibility」って出てきたら「処理者を連鎖させ、要求を処理するか次へ渡すか判断する設計」と思えばだいたいOK！
📖 おまけ：英語の意味
「Chain of Responsibility」 ＝ 責任の連鎖
💬 GoFの設計パターンの一つです。Apache Commons Chainは、この考え方をコマンドの列と処理継続・完了の戻り値として表現しています。概念の参考資料であり、このライブラリの新規採用を勧める説明ではありません。