1、party（團體）：
最初的通訊簿模型如下：
用團體來概括人和組織：
這樣做的好處是人和組織都可以同等的來考慮。對於**來說，我不需要知道這是屬於乙個公司的，還是只是屬於個人的。
2、組織層次
考慮下面一種情況，乙個跨國公司芳香咖啡機製造公司（acm），它有很多分公司，每個分公司又分成不同的區域子公司，而每個區域子公司又分成不同的部門，每個部門有很多銷售辦事處。
我們通常會這樣來建構：
好，現在我的需求改變了，分公司下面我不再設區域子公司，而是直接設定部門，那這個模型就需要修改了。
考慮如下的層次結構：
如果分公司下面我不再設區域子公司，而是直接設定部門，則只要把部門的約束條件改為parent must be operating unit就可以了。
好，我們的需求又變了，我們要建立乙個服務小組既要向銷售辦事處負責，又要向服務部門負責。如何來表示呢？
再加乙個關係啊：
如果有多種關係呢，這樣加下去也不是辦法啊？有沒有什麼辦法可以不用增加關係?而能表示多種關係呢？
3、組織結構
考慮一下在關係型資料庫中是如何處理多對多的關係呢？對！建立乙個新的表來表示，這邊套用一下的話，就變成了如下的結構：
這樣如果要增加關係，就只要增加相應的組織結構，還可以給定時間段呢。
好像忘了什麼東西了，對了，約束沒有加呢。約束該加在**呢？我感覺如果規則因為組織結構型別的不同而不同，我們完全可以把規則加到組織結構型別上，加上規則後就成了下圖：
難道這張圖只能用於組織結構嗎?非也。
設計模式之 責任鏈模式
在一些情況下，對乙個訊息 含事件 的響應和處理需要很多物件來參與，這些物件對訊息的處理有前後順序，形成乙個處理鏈條，但物件是否真正處理訊息有賴於在它之前的物件的處理策略，前乙個物件處理後，後乙個物件則不需參與處理，這就是責任鏈模式。現實中有很多類似的場景，比如上訪，上訪一般是從最基層的信訪部門接受信...
設計模式之（責任鏈模式）
chain of responsibleity 責任鏈模式 在責任鏈模式 中，很多物件由每乙個物件對其下家的引用而接。起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某乙個物件決定處理此請求。客戶並不知道鏈上的哪乙個物件最終處理這個請求，系統可以在不影響客戶端的情況下動態的重新組織鏈和分配責任。處理者...
設計模式之責任鏈模式
假設現在乙個公司的請假流程如下 一天及以下由小組組長審批，一天以上三天以下由經理審批，三天以上七天以下由老闆審批，七天以上直接勸退。如果每次請假時都很長的if else 來判斷該去找誰請假，很不容易擴充套件，我們使用責任鏈模式來實現。首先，是乙個抽象的父類 public abstract class...