責任鏈模式:乙個傳送者傳送請求,多個接收者鏈在一起接收請求,每個接收者持有下個接收者的引用。
例如:多個接收者:接收者a持有接收者b的引用,接收著b持有接收者c的引用,a->b->c形成了一條責任鏈。
乙個傳送者:傳送請求給接收者a,接收者a先判斷能不能處理,a不能處理丟給b處理,b不能處理丟給c處理。
當a可以處理,請求就不再往後傳遞了。
看以下**:
public void recieve(string param) else if (stringutils.equals(param, "b"))else if (stringutils.equals(param, "c"))
}
a,b,c的業務邏輯直接耦合在一起,並且傳送者不需要關注recieve方法的具體的實現細節
用責任鏈模式則很好的解決這個問題,使得a,b,c業務分離,乙個方法裡**的減少,**也看起來清爽多了,增強可讀性,並且對於傳送者隱藏實現的細節
1.定義乙個抽象類,a,b,c子類繼承實現具體的業務邏輯,處理各自的業務邏輯前判斷是否可以處理
2.a,b,c各自持有乙個下乙個業務處理環節的引用,a->b->c傳遞處理
**
import org.apache.commons.lang3.stringutils;
/***a,b,c的超類*/
public abstract class super
/*** 處理之前判斷是否可以執行
* @param param
*/protected void canhandler(string param)
if (null != next)
}/**
* 業務邏輯
*/public abstract void handler();
}
public class chaindemo
/*** 得到多個環節的一條業務鏈
* @return
*/public static super getchain()
/*** a業務環節
*/static class a extends super
@override
public void handler()
}/**
* b業務環節
*/static class b extends super
@override
public void handler()
}/**
* c業務環節
*/static class c extends super
@override
public void handler()
}}
設計模式之 責任鏈模式
在一些情況下,對乙個訊息 含事件 的響應和處理需要很多物件來參與,這些物件對訊息的處理有前後順序,形成乙個處理鏈條,但物件是否真正處理訊息有賴於在它之前的物件的處理策略,前乙個物件處理後,後乙個物件則不需參與處理,這就是責任鏈模式。現實中有很多類似的場景,比如上訪,上訪一般是從最基層的信訪部門接受信...
設計模式之(責任鏈模式)
chain of responsibleity 責任鏈模式 在責任鏈模式 中,很多物件由每乙個物件對其下家的引用而接。起來形成一條鏈。請求在這個鏈上傳遞,直到鏈上的某乙個物件決定處理此請求。客戶並不知道鏈上的哪乙個物件最終處理這個請求,系統可以在不影響客戶端的情況下動態的重新組織鏈和分配責任。處理者...
設計模式之責任鏈模式
假設現在乙個公司的請假流程如下 一天及以下由小組組長審批,一天以上三天以下由經理審批,三天以上七天以下由老闆審批,七天以上直接勸退。如果每次請假時都很長的if else 來判斷該去找誰請假,很不容易擴充套件,我們使用責任鏈模式來實現。首先,是乙個抽象的父類 public abstract class...