【GoFのデザインパターン】行動パターン：Chain of Responsibilityパターン

Chain of Responsibilityパターンの探求

今日はデザインパターンの一つ、Chain of Responsibility（責任の連鎖）パターンについて、教授と生徒の会話を通じて探求していきます。

導入

生徒：教授、Chain of Responsibilityパターンってどんな場合に使うんですか？

教授：それは、あるリクエストを複数のオブジェクトが処理できる場合に適しているパターンだよ。リクエストをオブジェクトのチェーンに沿って渡していくことで、そのリクエストを処理する最適なオブジェクトを動的に決定できるのだ。

パターンの必要性

生徒：なるほど、でもなぜそんなパターンが必要なんですか？

教授：いい質問だ。複数のオブジェクトが同じリクエストを処理できる場合、それをコード内で静的に決定することは柔軟性を欠くし、メンテナンスも困難になる。Chain of Responsibilityパターンを使うことで、処理を動的に割り当てることが可能になり、システムの柔軟性が向上するのだ。

使用しない場合の問題点

生徒：パターンを使用しないとどうなるんですか？

教授：パターンを使用しない場合、リクエストを処理するロジックが分散してしまい、特定のオブジェクトに依存する形になることが多い。これは、コードの変更が難しくなり、新しいリクエストタイプを追加したり、処理の順序を変更する際に、多くの手間がかかることを意味する。

生徒：それは大変そうですね。

教授：その通り。また、Chain of Responsibilityパターンを適切に使用することで、各オブジェクトが単一の責任を持つようになり、それによって、ソフトウェアの再利用性と拡張性が向上するのだ。

まとめ

生徒：Chain of Responsibilityパターンを使うことで、システムの柔軟性が向上し、メンテナンスが楽になるんですね。それに、再利用性や拡張性の面でも利点があると。

教授：正確にはその通り。Chain of Responsibilityは、適切な場面で使うことが重要だよ。全ての状況でこのパターンが最適とは限らないからね。

Chain of Responsibilityパターンの探究

この記事では、Chain of Responsibilityパターンについて解説し、C#での具体的なサンプルコードを通じて理解を深めていきます。

Chain of Responsibilityパターンとは？

Chain of Responsibilityパターンは、複数のオブジェクトを連鎖させて、リクエストを処理するデザインパターンです。リクエストを受け取ったオブジェクトが処理できない場合、次のオブジェクトにリクエストを渡していきます。

C#によるサンプルコード

以下は、Chain of ResponsibilityパターンをC#で実装したサンプルコードです。リクエストを処理する抽象クラスと、具体的な処理クラスを定義しています。

public abstract class Handler {
    protected Handler successor;

    public void SetSuccessor(Handler successor) {
        this.successor = successor;
    }

    public abstract void HandleRequest(int request);
}

public class ConcreteHandler1 : Handler {
    public override void HandleRequest(int request) {
        if (request >= 0 && request < 10) {
            Console.WriteLine($"{GetType().Name} handled request {request}");
        } else if (successor != null) {
            successor.HandleRequest(request);
        }
    }
}

public class ConcreteHandler2 : Handler {
    public override void HandleRequest(int request) {
        if (request >= 10 && request < 20) {
            Console.WriteLine($"{GetType().Name} handled request {request}");
        } else if (successor != null) {
            successor.HandleRequest(request);
        }
    }
}

class Program {
    static void Main(string[] args) {
        Handler h1 = new ConcreteHandler1();
        Handler h2 = new ConcreteHandler2();

        h1.SetSuccessor(h2);

        int[] requests = { 2, 5, 14, 22, 18, 3, 27, 20 };

        foreach (int request in requests) {
            h1.HandleRequest(request);
        }
    }
}

このコードでは、ConcreteHandler1 と ConcreteHandler2 がリクエストを処理する条件を異なる範囲で定義しています。このようにして、リクエストは適切なハンドラによって処理されます。

Chain of Responsibilityパターンの適用とその解決策

この記事では、デザインパターンの一つであるChain of Responsibilityパターンが問題解決にどのように役立つのか、教授と生徒の会話を通して解説します。

問題の発生

生徒：教授、システムの中でリクエストを処理する際に、どのオブジェクトが担当するかを決めるのが難しい時があります。この問題をどう解決すればいいですか？

教授：そのような時には、Chain of Responsibilityパターンが役立つよ。このパターンを使えば、リクエストをオブジェクトのチェーンを通じて一つずつ渡していき、適切なオブジェクトが処理するようにできるんだ。

パターンの適用

生徒：具体的にはどういうことですか？

教授：例えば、ログの処理を考えてみよう。異なるレベルのログ（情報、警告、エラー）があるとする。これらを処理するには、それぞれ専門のハンドラを用意して、チェーンのように連結させる。情報ログのハンドラが処理できなければ、次の警告ログのハンドラに渡し、それも処理できなければエラーログのハンドラに渡す方式だ。

解決した問題

生徒：なるほど、でも本当にそれで問題が解決するんですか？

教授：ええ、多くの問題が解決する。まず、各ハンドラが単一の責任を持つことになるから、システムの拡張性が高まる。新しい種類のログを処理する必要が出たら、新しいハンドラをチェーンに追加するだけでいい。また、各ハンドラは独立しているため、テストがしやすくなるし、再利用も容易になるよ。

生徒：確かに、そのようにするとシステムが柔軟に対応できそうですね。各ハンドラが独立していると、コードの見通しも良くなりそうです。

教授：正解。Chain of Responsibilityパターンは、システムのメンテナンス性と拡張性を向上させる強力なツールなんだ。ただし、チェーンを長くしすぎると処理が遅くなる可能性もあるから、注意が必要だよ。