現在很多程式設計師在面試的時候都遇到過這個問題---《貓叫了,老鼠跑了,主人醒了...>,實現乙個連動效果，我也遇到過,感覺這道面試題目挺經典的,挺考驗物件導向設計(ood)的能力,雖然是個很簡單的例子,但要考慮到程式的擴充套件性。比如說有新的需求,要求後面再加上狗叫了,那些寫的過死且繁瑣的**就要來次大**了;再比如說又變需求了，貓叫了是因為被跳蚤咬的，那跳蚤就成為了導火線，就算是用事件和介面寫出的擴充套件性很強的程式，也會有點蔫了......
這麼一連串的反應是由乙個行為所引起的，或者是貓叫，亦或者是乙個按鈕的點選引發，如何能讓這一連串反映的擴充套件性更強，能更堅強的面對新的需求。這就需要乙個更佳的思路，更佳的設計模式，今天無意想起了這個問題，也根據我的思路寫了一套模式，下面就詳細的說下我的想法：
無論是貓叫，還是老鼠跑，都是乙個行為，我們把這個行為抽象出乙個基類：
1 namespace newcatandmouse
2 10 set
11 }
12 13 ///
14 /// 抽象出的行為
15 ///
16 public abstract void action();
17 }
18 }
現在我們再建乙個中間層，用來處理這些行為：
1 namespace newcatandmouse
2 12
13 ///
14 /// 執行
15 ///
16 public void execute()
17
20 }
21 }
現在我們一一實現貓、老鼠和主人（從基類繼承）：
1 namespace newcatandmouse
2 9 }
10 }
1 namespace newcatandmouse
2 9 }
10 }
1 namespace newcatandmouse
2 9 }
10 }
三個實現類完成了。現在一一例項化，組合呼叫？不，那樣客戶端會顯的臃腫而醜陋，有人說：**是門技術，更是門藝術。所以我們的客戶端**應當越簡潔越好。所以，我們把需要的東西寫在配置檔案裡：
1 <?xml version="1.0" encoding="utf-8" ?>
2 3
4
5
11 然後我們再做乙個類來處理配置檔案：
1 namespace newcatandmouse
2 17 }
18 }
下面就是客戶端**了：
這樣就可以了，如果需要新的子類直接繼承基類，再在配置檔案新增乙個子類屬性就可以了。而且可以再配置檔案裡自由的組合而無需改動客戶端的**，符合了開放--封閉原則。
但由於用了反射，所以效能會有些差。而且如果實現類需要有新功能，就得在基類新增，如果功能太多基類就會變的臃腫不堪。所以，它也是有侷限性的，最好是派生類不多而且行為較為統一。
可能有人會說：那麼簡單的**也好意思發上來。我想說：功能總能實現，就看怎樣實現。這只是乙個思路，由於更多的人把自己總結的不錯的設計思路分享出來，所以我們才能進步。
最近看設計模式有些上癮，所以手癢也來湊湊熱鬧，但畢竟學程式的時間太短，經驗太淺，所以可能有很多問題。希望大家幫我指正，希望能和大家一起努力，共同進步。
附：讓板磚來的更激烈些吧！
事件 貓和老鼠觀察者模式
委託與事件的區別 事件在哪個類定義，就要在哪個類發布，委託 都能發布 using system namespace 008事件 public class people public int age public people 建構函式或者說是初始化建立物件 public void eat publi...
觀察者模式的經典應用 貓叫 燒開水
code 燒開水 using system using system.collections.generic using system.text namespace delegate 可以供繼承自 heater 的類重寫，以便繼承類拒絕其他物件對它的監視 protected virtual void...
python觀察者模式 python 觀察者模式
python 觀察者模式 前言e 寫的倉促就不截uml類圖了，書本chapter10，p313能看到圖 一旦觀察的主題有更新，就會通知到觀察者們，下面的例子是最簡單的乙個觀察者範例，假設這是一群投機分子密切關注 軍 火 倉庫的產品與數量變動 class inventory def init self...