CoRモード
CoR(Chain of Responsibility)すなわち職責チェーン設計モード:要求の送信者と受信者との結合関係を回避するために、複数のオブジェクトが要求(Request)を処理する機会を与える.これらのオブジェクトをチェーンに接続し、オブジェクトが彼を処理するまで、このチェーンに沿ってリクエストを渡します.ロールチェーン設計モードには、(1)要求(Request):パッケージング要求情報(2)プロセッサ(Handler):処理要求(Request)の3つのロールがあります.1つの特定のプロセッサは、伝達された要求を処理できない場合は、一般的に1つの要求のみを処理します.これにより、リクエストは職責チェーンの次のプロセッサ(後続プロセッサsuccessor)に渡されます.(3)クライアント(Client):送信要求定義はこれ以上言わず,実装を直接見る.以下は従来のCoR実装である:1抽象要求を表すインタフェース(Request)
public interface Request{
//......
} 2,Requestインタフェースを実装する実装クラス,HelpRequest,PrintRequest,SaveRequestはテキストエディタがあると仮定し,ユーザインタフェースには3つのボタンHelpがあり,PrintとSave HelpRequestはユーザがHelpボタンをクリックしたときに生じるヘルプ要求を表す.
PrintRequestは、ユーザがPrintボタンをクリックしたときに生じる印刷要求を表し、SaveRequestは、ユーザがSaveボタンをクリックしたときに生じる保存要求を表す.
//
public class HelpRequest implements Request{
//......
}
//
public class PrintRequest implements Request{
//......
}
//
public class SaveRequest implements Request{
//......
}
3,抽象プロセッサを表すインタフェースHandler:
public interface Handler{
void handleRequest(Request request);
}4,実装プロセッサインタフェースの実装クラスHelpHandler,PrintHandler,SaveHandler:HelpHandler処理支援要求(HelpRequest)
public class HelpHandler implements Handler{
//
private Handler successor;
public HelpHandler(Handler successor){this.successor = successor;}
public void handleRequest(Request request) {
if(request instanceof HelpRequest){
System.out.println("HelpHandler handle " +request.getClass().getSimpleName());
// handle request
}else{
System.out.println("PrintHandler can't handle "+request.getClass().getSimpleName());
if(successor != null)
successor.handleRequest(request);
}
}
}PrintHandler印刷要求の処理(PrintRequest)
public class PrintHandler implements Handler{
//
private Handler successor;
public PrintHandler(Handler successor){this.successor = successor;}
public void handleRequest(Request request) {
if(request instanceof PrintRequest){
System.out.println("PrintHandler handle "+request.getClass().getSimpleName());
// handle request
}else{
System.out.println("PrintHandler can't handle "+request.getClass().getSimpleName());
if(successor != null)
successor.handleRequest(request);
}
}
}SaveHandler処理保存要求(SaveRequest)
public class SaveHandler implements Handler{
//
private Handler successor;
public SaveHandler(Handler successor){this.successor = successor;}
public void handleRequest(Request request) {
if(request instanceof SaveRequest){
System.out.println("SaveHandler handle "+request.getClass().getSimpleName());
// handle request
}else{
System.out.println("SaveHandler can't handle "+request.getClass().getSimpleName());
if(successor != null)
successor.handleRequest(request);
}
}
}5,クライアントClientクラス
public class Client{
public static void main(String[] args){
Handler handler1 = new HelpHandler(null);
Handler handler2 = new PrintHandler(handler1);
Handler handler3 = new SaveHandler(handler2);
handler3.handleRequest(new HelpRequest());
handler3.handleRequest(new PrintRequest());
handler3.handleRequest(new SaveRequest());
}
}Clientクラスの出力を実行するには、SaveHandler can't handle HelpRequestPrintHandler can't handle HelpRequestHelpHandler handle HelpRequest SaveHandler can't handle PrintRequestPrintHandler handle PrintRequest SaveHandler SaveRequest関連リンク:http://www.iteye.com/topic/411222 CoRモード(別)
-----------------------------------------------------
抽象クラスでも良いのですが、handleRequestの(1)このプロセッサがこのリクエストを処理できるかどうかと(2)対応するリクエストを処理できるかどうかという2つの機能を分離し、抽象メソッドとして定義してサブクラス(具体的なプロセッサ)に実現させる
public abstract class AbstractHandler implements Handler {
protected Handler successor;
public AbstractHandler(Handler successor) {
this.successor = successor;
}
//finalと定義し、布団類はを継承できない
public final void handleRequest(Request request) {
if (canHandleRequest(request)) {
handleRequestMyself(request);
} else {
if (successor != null)
successor.handleRequest(request);
}
}
//このプロセッサは要求全体を処理できるかどうか
protected abstract boolean canHandleRequest(Request request);
//対応要求の処理 protected abstract void handleRequestMyself(Request request);
}
-----------------------------------------------------
PipeLine + Value
lishuaibtは
実は純粋な責任チェーンモデル私の理解は、責任逃れのモデルであり、責任を負うモジュールがこの要求を受信し、この要求を処理することを知っている.このような状況は確かにあまり多くないでしょう.(個人的にはね).pipelineという概念は、従来のturbineフレームワーク(非常に優れたMVCフレームワーク)で使われていた.その大まかなパターンと概念は以下の通りである:PipeLineはサーブレットのFilterChainの概念に似ており、valveはFilterに似ている.このPipeLineの各Valveノードを流れるリクエストであり、このノードは純粋な責任チェーンモードのように、責任を押し下げるのではなく、このリクエストに対して一定の処理を行う.対応した処理をした後、処理後の要求を次のValveに渡して処理したいのです.例を挙げると、一度サーブレットを要求する過程で、CharSetの設定、権限検証、URLの解析など、すべての要求に必要な処理がある場合があります.これらの処理は要求のChainを構成し、すべての要求はこれらの処理を経て、次の具体的な業務処理を行うことができます.この时、これらの共通の処理を抽象化してpipelineを作ることができて、このpipelineはvalveノードで构成されたことがあります...差が少ないからそういう意味でしょう...文字で形容するのは確かに言いにくい.