本筆記摘抄自：https://www.cnblogs.com/PatrickLiu/p/7928521.html，記錄一下學習過程以備後續查用。 一、引言 今天我們要講行為型設計模式的第四個模式--觀察者模式，先從名字上來看。觀察者模式可以理解為既然有“觀察者”，那肯定就有“被觀察者”了。“觀察者” ...
本筆記摘抄自：https://www.cnblogs.com/PatrickLiu/p/7928521.html，記錄一下學習過程以備後續查用。
一、引言
今天我們要講行為型設計模式的第四個模式--觀察者模式，先從名字上來看。觀察者模式可以理解為既然有“觀察者”，那肯定就有“被觀察者”了。“觀察者”
監視著“被觀察者”，如果“被觀察者”有所行動，“觀察者”就會做出相應的動作來回應。聽起來是不是有點像“諜戰”的味道？比如“諜影重重”那類優秀的影片。
觀察者模式在現實生活中，實例其實是很多的，比如：八九十年代我們訂閱的報紙，我們會定期收到報紙，因為我們訂閱了。銀行可以給儲戶發手機簡訊，
也是觀察者模式很好的使用的例子，因為我們訂閱了銀行的簡訊業務，當我們賬戶餘額發生變化就會收到通知。還有很多，我就不一一列舉了，發揮大家的
想象吧。好了，接下來，就讓我們看看該模式具體是怎麼實現的吧。
二、觀察者模式介紹
觀察者模式：英文名稱--Observer Pattern；分類--行為型。
2.1、動機（Motivate）
在軟體構建過程中，我們需要為某些對象建立一種“通知依賴關係”--一個對象（目標對象）的狀態發生改變，所有的依賴對象（觀察者對象）都將得到通知。
如果這樣的依賴關係過於緊密，將使軟體不能很好地抵禦變化。使用面向對象技術，可以將這種依賴關係弱化，並形成一種穩定的依賴關係，從而實現軟體體
繫結構的松耦合。
2.2、意圖（Intent）
定義對象間的一種一對多的依賴關係，以便當一個對象的狀態發生改變時，所有依賴於它的對象都得到通知並自動更新。——《設計模式》GoF
2.3、結構圖
2.4、模式的組成
可以看出，在觀察者模式的結構圖有以下角色：
1）抽象主題角色（Subject）：抽象主題把所有觀察者對象的引用保存在一個列表中，並提供增加和刪除觀察者對象的操作，抽象主題角色又叫做抽象被觀
察者角色，一般由抽象類或介面實現。
2）抽象觀察者角色（Observer）：為所有具體觀察者定義一個介面，在得到主題通知時更新自己，一般由抽象類或介面實現。
3）具體主題角色（ConcreteSubject）：實現抽象主題介面，具體主題角色又叫做具體被觀察者角色。
4）具體觀察者角色（ConcreteObserver）：實現抽象觀察者角色所要求的介面，以便使自身狀態與主題的狀態相協調。
2.5、觀察者模式的具體實現
觀察者模式在顯示生活中也有類似的例子，比如：我們訂閱銀行簡訊業務，當我們賬戶發生改變，我們就會收到相應的簡訊。類似的還有微信訂閱號，今天
我們以訂閱銀行簡訊業務為例來講講觀察者模式的實現，實現代碼如下：
class Program { /// <summary> /// 銀行簡訊系統抽象介面，是被觀察者--該類型相當於抽象主題角色Subject。 /// </summary> public abstract class BankMessageSystem { protected IList<Depositor> observers; //構造函數初始化觀察者列表實例 protected BankMessageSystem() { observers = new List<Depositor>(); } //增加預約儲戶 public abstract void Add(Depositor depositor); //刪除預約儲戶 public abstract void Delete(Depositor depositor); //通知儲戶 public void Notify() { foreach (Depositor depositor in observers) { if (depositor.AccountIsChanged) { depositor.Update(depositor.Balance, depositor.OperationDateTime); //賬戶發生變化並且通知後，則可認為賬戶已無變化。 depositor.AccountIsChanged = false; } } } } /// <summary> /// 廣東銀行簡訊系統，是被觀察者--該類型相當於具體主題角色ConcreteSubject。 /// </summary> public sealed class GuangDongBankMessageSystem : BankMessageSystem { //增加預約儲戶 public override void Add(Depositor depositor) { //應該先判斷該用戶是否已預約？如未預約則增加到列表中，這裡簡化了。 observers.Add(depositor); } //刪除預約儲戶 public override void Delete(Depositor depositor) { //應該先判斷該用戶是否有預約？如有則刪除，否則不操作，這裡簡化了。 observers.Remove(depositor); } } /// <summary> /// 儲戶的抽象介面--相當於抽象觀察者角色（Observer） /// </summary> public abstract class Depositor { //儲戶的名稱，假設是唯一的。 public string Name { get; private set; } //儲戶的餘額 public int Balance { get; private set; } //賬戶操作時間 public DateTime OperationDateTime { get; set; } //賬戶是否發生變化 public bool AccountIsChanged { get; set; } //初始化狀態數據 protected Depositor(string name, int total) { Name = name; Balance = total; //存款總額等於餘額 AccountIsChanged = false; //賬戶未發生變化 } //取錢 public void GetMoney(int num) { if (num <= Balance && num > 0) { Balance -= num; AccountIsChanged = true; OperationDateTime = DateTime.Now; } } //更新儲戶狀態 public abstract void Update(int currentBalance, DateTime dateTime); } /// <summary> /// 廣東的具體儲戶--相當於具體觀察者角色ConcreteObserver /// </summary> public sealed class GuangDongDepositor : Depositor { public GuangDongDepositor(string name, int total) : base(name, total) { } public override void Update(int currentBalance, DateTime dateTime) { Console.WriteLine(string.Format(Name + "，您的賬戶餘額有變化，發生時間：{0}，當前餘額：{1}元。", dateTime.ToString(), currentBalance.ToString())); } } static void Main(string[] args) { #region 觀察者模式 //假設有3位儲戶，都是武林高手，也比較有錢。 Depositor huangFeiHong = new GuangDongDepositor("黃飛鴻", 3000); Depositor fangShiYu = new GuangDongDepositor("方世玉", 1300); Depositor hongXiGuan = new GuangDongDepositor("洪熙官", 2500); BankMessageSystem guangDongBank = new GuangDongBankMessageSystem(); //這三位開始訂閱銀行簡訊業務 guangDongBank.Add(huangFeiHong); guangDongBank.Add(fangShiYu); guangDongBank.Add(hongXiGuan); //早上黃飛鴻取了100塊錢 huangFeiHong.GetMoney(100); guangDongBank.Notify(); //中午黃飛鴻和方世玉各取了200塊 huangFeiHong.GetMoney(200); fangShiYu.GetMoney(200); guangDongBank.Notify(); //晚上他們三個都取了錢 huangFeiHong.GetMoney(300); fangShiYu.GetMoney(300); hongXiGuan.GetMoney(300); guangDongBank.Notify(); Console.Read(); #endregion } }View Code
運行結果如下：
觀察者模式有些麻煩的地方就是關於狀態的處理，大家可以細細體會一下。模式還是要多寫多練習，裡面的道理就不難理解了。
三、觀察者模式的實現要點
使用面向對象的抽象，Observer模式使得我們可以獨立地改變目標與觀察者（面向對象中的改變不是指改代碼，而是指擴展、子類化、實現介面），從而使
二者之間的依賴關係達到松耦合。目標發送通知時，無需指定觀察者，通知（可以攜帶通知信息作為參數）會自動傳播。觀察者自己決定是否需要訂閱通知，
目標對象對此一無所知。
在C#的event中，委托充當了抽象的Observer介面，而提供事件的對象充當了目標對象。委托是比抽象Observer介面更為松耦合的設計。
3.1、觀察者模式的優點
1）觀察者模式實現了表示層和數據邏輯層的分離，並定義了穩定的更新消息傳遞機制，同時抽象了更新介面，使得可以有各種各樣不同的表示層，即觀察者。
2）觀察者模式在被觀察者和觀察者之間建立了一個抽象的耦合，被觀察者並不知道任何一個具體的觀察者，只是保存著抽象觀察者的列表，每個具體觀察者
都符合一個抽象觀察者的介面。
3）觀察者模式支持廣播通信。被觀察者會向所有的註冊過的觀察者發出通知。
3.2、觀察者模式的缺點
1）如果一個被觀察者有很多直接和間接的觀察者時，將所有的觀察者都通知到會花費很多時間。
2）雖然觀察者模式可以隨時使觀察者知道所觀察的對象發送了變化，但是觀察者模式沒有相應的機制使觀察者知道所觀察的對象是怎樣發生變化的。
3）如果在被觀察者之間有迴圈依賴的話，被觀察者會觸發它們之間進行迴圈調用，導致系統崩潰，在使用觀察者模式應特別註意這點。
四、.NET中觀察者模式的實現
其實在Net裡面實現的觀察者模式做了一些改變，用委托或者說是事件來實現觀察者模式。事件我們都很明白，可以註冊控制項的事件，當觸發控制項的動作時候，
相應的事件就會執行，在事件的執行過程中我們就可以做相關的提醒業務。這裡關於觀察者模式在Net裡面的實現就不說了，如果大家不明白，可以多看看相關委
托或者事件的相關資料。
五、總結
這個模式結合實例理解是很容易的，模式的使用我們不能照搬，要理解，當然多多聯繫和寫代碼也是必不可少的，我們使用模式的一貫宗旨是通過重構和迭代，
在我們的代碼中實現相應的模式。
