場景：白眉大俠與江湖
描述：江湖綠林道與開封府。小嘍兵與小寨主，小七傑可以辦案。俠客要小五義。劍客要劍客對付。
（一）開封府
public
abstract
class
kaifentfu
public
abstract
void handle(lulin lulin); }
（二）小七傑，小五義，小五義老師
public
class
xiaoqijie : kaifentfu
else
} }
public
class
xiaowuyi : kaifentfu
else
} }
public
class
jianke : kaifentfu
else
} }
（三）綠林
public
enum
etype
public
class
lulin
public
etype lulintype }
（四）測試
public
void testchainofresponsibility() );
_list.add(new
lulin );
_list.add(new
lulin );
_list.add(new
lulin );
_list.add(new
lulin );
_list.add(new
lulin );
_list.add(new
lulin );
foreach(lulin ll in _list)
_k1.handle(ll); }
結果：
劍客，小五義的老師可以處理了！
小小嘍兵和小寨主，小七傑可以處理了！
俠客，小五義可以處理了！
小小嘍兵和小寨主，小七傑可以處理了！
小小嘍兵和小寨主，小七傑可以處理了！
劍客，小五義的老師可以處理了！
小小嘍兵和小寨主，小七傑可以處理了！
在軟體構建過程中，乙個請求可能被多個物件處理，但是每個請求在執行時只能有乙個接受者，如果顯示指定，將必不可少地帶來請求傳送者與接受者的緊耦合。
如何使請求的傳送者不需要指定具體的接受者？讓請求的接受者自己在執行時決定來處理請求，從而使兩者解耦。
使多個物件都有機會處理請求，從而避免請求的傳送者和接收者之間的耦合關係。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有乙個物件處理它為止。
這個例子裡，這個鏈沒有盡頭（沒有對全部可能的請求進行處理），它沒有對盡可能的請求做出處理。但在鏈的結尾，應當把請求處理完畢。
模式例項之 裝飾例項
場景 遊戲修改器 描述 角色的級別太低，技能也弱，但關卡難度太大。往往一上來來不及回血，或遊戲設定回血太慢。這裡用遊戲修改器。一 角色 public abstract class role public int mp public int hp public abstract void restor...
設計模式之職責鏈模式
如果我們現在有乙個需求,乙個人他生了病,這個病要在 醫院才能看,但是這個病人並不清楚,就先去了一級醫院,一級醫院的醫生告訴他你的病要去二級醫院看,二級醫院也告訴他 你的病我這裡看不了,你要去 醫院才能看,最後他去 醫院把病看好了.這個過程直接寫成 class patient this.patient...
設計模式之職責鏈模式
職責鏈模式 使多個物件都有機會處理請求，從而避免請求的傳送者和接收者之間的耦合關係。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有乙個物件處理它為止。適用場景 1 有多個的物件可以處理乙個請求，哪個物件處理該請求執行時刻自動確定 2 在不明確指定接收者的情況下，向多個物件中的乙個提交乙個請求 ...