假設現在乙個公司的請假流程如下：一天及以下由小組組長審批，一天以上三天以下由經理審批，三天以上七天以下由老闆審批，七天以上直接勸退。
如果每次請假時都很長的if…else…來判斷該去找誰請假，很不容易擴充套件，我們使用責任鏈模式來實現。
首先，是乙個抽象的父類
public abstract class handler
else
else
}} /// /// 設定下乙個處理請假請求的人
///
///
public void setnext(handler nexthandler)
/// /// 這個請假天數是否在自己的職責範圍內
///
///
protected abstract bool isinresposibilityscope(float days);
/// /// 領導簽字，表示請假得到了審批
///
protected abstract void sign();
}
public class groupleader : handler
return false;
} protected override void sign()
}
public class manager : handler
return false;
} protected override void sign()
}
public class boss:handler
return false;
} protected override void sign()
}
class program
}
主管簽字同意了
經理簽字同意了
老闆簽字同意了
請假太久了，請直接提交辭職報告吧！
責任鏈模式的定義：使多個物件都能夠處理請求，從而避免請求的傳送者和接受者的耦合關係。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有乙個物件處理它為止。
在這個請假流程的處理中，請假者不需要知道他的請求需要提交給誰，只需要提交給責任鏈的第乙個物件就行了，如果第乙個物件處理不了的話，會自動交給鏈上的下乙個物件。這就實現了請求的傳送者和接收者解耦了。
如果處理請求的邏輯變了，如，小組長可以審批2天以內的請假流程了，或者新增了乙個總監職位，可以處理一周內的請假流程等，只需要修改特定的類，或擴充套件新類，請求的傳送者是不需要知道的，傳送請求的**也不需要修改。
設計模式之 責任鏈模式
在一些情況下，對乙個訊息 含事件 的響應和處理需要很多物件來參與，這些物件對訊息的處理有前後順序，形成乙個處理鏈條，但物件是否真正處理訊息有賴於在它之前的物件的處理策略，前乙個物件處理後，後乙個物件則不需參與處理，這就是責任鏈模式。現實中有很多類似的場景，比如上訪，上訪一般是從最基層的信訪部門接受信...
設計模式之（責任鏈模式）
chain of responsibleity 責任鏈模式 在責任鏈模式 中，很多物件由每乙個物件對其下家的引用而接。起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某乙個物件決定處理此請求。客戶並不知道鏈上的哪乙個物件最終處理這個請求，系統可以在不影響客戶端的情況下動態的重新組織鏈和分配責任。處理者...
設計模式之責任鏈模式
一 定義 使多個物件都有接受請求的機會，而只有符合自己條件的物件才能處理這個請求。二 例項 2.1 例項 有乙個公司x，每乙個員工都有向公司借錢的機會，但是根據數目的不同需要的審批人也不同，比如1000到5000是等級1，只需要 研發組的小組長同意就行了，但是5000到10000是等級2，需要經理同...