実生活では、多くの場合、そのような場合：複数のオブジェクトを求める要求が扱うが、処理条件や各オブジェクトの権限異なることができます。例えば、従業員が去る、指導者が部門長、次長、ゼネラルマネージャーを持っていますが、別の日にすべての指導者が承認することができ休暇を与えることができる、従業員は、彼らが残している日数に応じて異なるリーダーシップの署名を見なければならないが、また、情報の従業員は難易度を増加させる、指導者のそれぞれの名前、電話と住所を覚えておく必要があります。そのようなリーダーシップを探している旅行償還、ゲームを「過ごすために太鼓パス」での生活など、多くのそのような例があります。
コンピュータのハードウェア及びソフトウェアでデータグラム転送ネットワークバスのように、また、関連する実施例で、各コンピュータは、受信したアドレスは、独自の目標アドレスと同じであるかどうかを決定するために、それは例外の種類に応じているかどうか、例外処理、処理プログラムが決定します例外;存在 Struts2のの インターセプタ、JSP と サーブレット 責任のパターンのチェーンが使用される場合に解くことができるすべてがフィルタ等の、。
モデルの定義と特性
責任の定義された鎖（責任の連鎖）モード：要求の送信者と複数のハンドラを回避するために、一緒に結合され、その心が参照により処理されたすべてのリクエストその次のオブジェクトと先行するオブジェクト要求によってチェーンに接続されています。要求が発生したとき、要求はこれまでオブジェクトハンドルまで鎖に沿って伝送されます。
注：Chain of Responsibilityパターンは、Chain of Responsibilityパターンと呼ばれています。
Chain of Responsibilityパターンでは、顧客は単に要求を気にせずに要求し、転送処理の詳細を処理するために、責任のチェーンに要求を送信し、その責任の送信者と、ハンドラ要求チェーンが切り離さ要求します。
Chain of Responsibilityパターンは、オブジェクトの行動パターンであり、その主な利点は次の通りです。
- オブジェクト間の結合を減少させます。このモードでは、最終的にオブジェクト要求および処理チェーン、お互いにも明確なメッセージを持っていない送信者と受信者の必要性である構造であるか分からないオブジェクトの必要性を可能にします。
- システムの拡張性を強化。開閉の原則を満たすために必要に応じて、要求処理の新しいカテゴリを追加することができます。
- オブジェクトに責任を割り当ての柔軟性を強化。ワークフローが変化した場合、あなたは動的にチェーン内のメンバーを変更したり、自分のためにも動的に追加または責任を削除することができ動員することができます。
- 責任の連鎖は、オブジェクト間の接続を簡素化します。各オブジェクトは、ちょうどif文のか···それ以外の場合は、多数の使用を回避する、他のすべてのハンドラを維持するために参照することなく、その後継への参照を保持します。
- 共同責任。唯一の自分の仕事のプロセスを扱う、次のオブジェクトの処理に渡すべきではありません各クラスの必要性は、単一の責任クラスの原則に沿って、責任範囲のすべての種類をクリアし、完了です。
主な欠点は次の通り。
- 私たちは、それぞれの要求を処理しなければならないことを保証することはできません。リクエストの受信者が明確ではないとして、我々はそれが処理されることを保証することはできませんが、リクエストがチェーンの最後に渡された可能性があり、処理されていません。
- 比較の長いデューティチェーンは、処理複数のオブジェクトを含むことができる要求を処理し、システムのパフォーマンスが影響を受けるであろう。
- お客様は終わりを確保するために、責任の確立チェーンの合理性に依存して、クライアントの複雑さを増す、このようなサイクルの呼び出しをもたらすことができるように誤った設定デューティチェーンと原因システムエラー、に起因する可能性があります。
アーキテクチャと実装モデル
通常は、データデューティチェーンリンクリストによって実現することができるデータ構造。
1.構造モデル
デューティ・チェーンは、主に次の役割が含まれています。
- 抽象ハンドラ（ハンドラ）の役割：インターフェイスに処理要求を定義し、抽象後続の接続を含む処理方法。
- 詳細ハンドラは（コンクリートハンドラ）キャスト：要求は、それが前方にそうでない場合には、後継者に要求を処理することができれば、抽象ハンドラが処理方法を実装し、プロセスは、この要求か否かを判断します。
- 顧客クラス（クライアント）役割：処理チェーンを作成するには、ターゲットの特定のハンドラチェーンの最初の要求を提出し、それが転送処理の詳細を気にして、要求を処理しません。
図1に示す構造。図2に示すように、クライアントが責任チェーンを提供することができます。
図1は、Chain of Responsibilityパターンの構成図です。
責任の図2の鎖
実現の2モード
次のように責任パターンコードの鎖は、以下のとおりです。
package chainOfResponsibility;
public class ChainOfResponsibilityPattern
{
public static void main(String[] args)
{
//组装责任链
Handler handler1=new ConcreteHandler1();
Handler handler2=new ConcreteHandler2();
handler1.setNext(handler2);
//提交请求
handler1.handleRequest("two");
}
}
//抽象处理者角色
abstract class Handler
{
private Handler next;
public void setNext(Handler next)
{
this.next=next;
}
public Handler getNext()
{
return next;
}
//处理请求的方法
public abstract void handleRequest(String request);
}
//具体处理者角色1
class ConcreteHandler1 extends Handler
{
public void handleRequest(String request)
{
if(request.equals("one"))
{
System.out.println("具体处理者1负责处理该请求！");
}
else
{
if(getNext()!=null)
{
getNext().handleRequest(request);
}
else
{
System.out.println("没有人处理该请求！");
}
}
}
}
//具体处理者角色2
class ConcreteHandler2 extends Handler
{
public void handleRequest(String request)
{
if(request.equals("two"))
{
System.out.println("具体处理者2负责处理该请求！");
}
else
{
if(getNext()!=null)
{
getNext().handleRequest(request);
}
else
{
System.out.println("没有人处理该请求！");
}
}
}
}次のようにプログラムの結果は以下のとおりです。
具体处理者2负责处理该请求！応用例のモード
Chain of Responsibilityパターンを使用して、[実施例1]は彼の休暇の承認モジュールを設計します。
分析：に等しいかそれ以下ならば、所定の学生が二日残すよりも、教師が承認することができる。以下、または7日に等しい、ディーンは承認、未満または10日に等しい、ディーンは承認することができる、そうでない場合は承認されていない。責任のこの実施例のチェーンでの使用に適しました実装パターン。
まず、抽象ハンドラであるリーダークラス（リーダー）を、定義し、それが次のリーダーのポインタへのポインタを含む次の抽象処理方法のhandleRequest（int型LeaveDays）プロセスのダミーバー;その後、クラスのカテゴリ（ClassAdviser）を定義し、抽象ハンドラのサブクラスであるクラス（DepartmentHead）とディーン・クラス（ディーン）の頭部は、ハンドラは、それに対処する資格がない場合は、自分の力に基づいて、親クラスのhandleRequest（int型LeaveDays）メソッドを実現する必要がある、特定のです最後まで次の特定のハンドラへの休暇のためのアプリケーション、顧客クラスは、ヘッド（教師）への休暇のための処理チェーン、および特定のハンドラチェーンを作成する責任があります。図3に示すように構成図です。
図3は、図休暇の承認モジュール構成を要求します。
コードは以下の通りであります：
package chainOfResponsibility;
public class LeaveApprovalTest
{
public static void main(String[] args)
{
//组装责任链
Leader teacher1=new ClassAdviser();
Leader teacher2=new DepartmentHead();
Leader teacher3=new Dean();
//Leader teacher4=new DeanOfStudies();
teacher1.setNext(teacher2);
teacher2.setNext(teacher3);
//teacher3.setNext(teacher4);
//提交请求
teacher1.handleRequest(8);
}
}
//抽象处理者：领导类
abstract class Leader
{
private Leader next;
public void setNext(Leader next)
{
this.next=next;
}
public Leader getNext()
{
return next;
}
//处理请求的方法
public abstract void handleRequest(int LeaveDays);
}
//具体处理者1：班主任类
class ClassAdviser extends Leader
{
public void handleRequest(int LeaveDays)
{
if(LeaveDays<=2)
{
System.out.println("班主任批准您请假" + LeaveDays + "天。");
}
else
{
if(getNext() != null)
{
getNext().handleRequest(LeaveDays);
}
else
{
System.out.println("请假天数太多，没有人批准该假条！");
}
}
}
}
//具体处理者2：系主任类
class DepartmentHead extends Leader
{
public void handleRequest(int LeaveDays)
{
if(LeaveDays<=7)
{
System.out.println("系主任批准您请假" + LeaveDays + "天。");
}
else
{
if(getNext() != null)
{
getNext().handleRequest(LeaveDays);
}
else
{
System.out.println("请假天数太多，没有人批准该假条！");
}
}
}
}
//具体处理者3：院长类
class Dean extends Leader
{
public void handleRequest(int LeaveDays)
{
if(LeaveDays<=10)
{
System.out.println("院长批准您请假" + LeaveDays + "天。");
}
else
{
if(getNext() != null)
{
getNext().handleRequest(LeaveDays);
}
else
{
System.out.println("请假天数太多，没有人批准该假条！");
}
}
}
}
//具体处理者4：教务处长类
class DeanOfStudies extends Leader
{
public void handleRequest(int LeaveDays)
{
if(LeaveDays<=20)
{
System.out.println("教务处长批准您请假"+LeaveDays+"天。");
}
else
{
if(getNext()!=null)
{
getNext().handleRequest(LeaveDays);
}
else
{
System.out.println("请假天数太多，没有人批准该假条！");
}
}
}
}次のようにプログラムの結果は以下のとおりです。
院长批准您请假8天。あなたは学長クラスを追加する場合は、次のように、生徒たちは、それはまた、非常にシンプルで、20日間の休暇を与えることがあります。
//具体处理者4:教务处长类
class DeanOfStudies extends Leader
{
public void handleRequest(int LeaveDays)
{
if(LeaveDays<=20)
{
System.out.println("教务处长批准您请假"+LeaveDays+"天。");
}
else
{
if(getNext()!=null)
{
getNext().handleRequest(LeaveDays);
}
else
{
System.out.println("请假天数太多，没有人批准该假条！");
}
}
}
}シーンモードの応用
フロント、以下のアプリケーションシナリオを記述し、Chain of Responsibilityパターンの構造と特性について言われている、Chain of Responsibilityパターンは、一般的に次のような状況で使用されています。
- オブジェクトの複数のオブジェクトが自動的にリクエスト処理ランタイムによって決定される要求を処理することができます。
- 動的要求指定にオブジェクトのセットを処理する、または新しいプロセッサを追加します。
- 明示的にハンドラを要求せずに、複数のハンドラに要求を提出します。
拡張モード
以下の2つのケースデューティチェーン。
- 責任パターンの純粋なチェーン：要求を処理するために1つのハンドラオブジェクトと特定のハンドラによって受信されなければならない要求が2つのだけのアクションのいずれか取ることができます。自分の治療（責任を）;にバックを渡します家の下で治療。
- 不純なデューティチェーン：要求は、残りの次のホーム責任に渡された場合の一部の責任を負うために、特定のオブジェクト・ハンドラで許可され、最終的な要求は、任意の受信側オブジェクトによって受信することができません。
