.NET設計模式（19）：觀察者模式（Observer Pattern）

時間  2020-05-12
標籤 設計 模式 觀察者 observer pattern 欄目 Hadoop 简体版
原文   原文鏈接
概述
在軟件構建過程當中，咱們須要爲某些對象創建一種「通知依賴關係」 ——一個對象（目標對象）的狀態發生改變，全部的依賴對象（觀察者對象）都將獲得通知。若是這樣的依賴關係過於緊密，將使軟件不能很好地抵禦變化。使用面向對象技術，能夠將這種依賴關係弱化，並造成一種穩定的依賴關係。從而實現軟件體系結構的鬆耦合。
意圖
定義對象間的一種一對多的依賴關係,當一個對象的狀態發生改變時, 全部依賴於它的對象都獲得通知並被自動更新。[GOF 《設計模式》]
結構圖
圖1 Observer模式結構圖
生活中的例子
觀察者定義了對象間一對多的關係，當一個對象的狀態變化時，全部依賴它的對象都獲得通知而且自動地更新。拍賣演示了這種模式。每一個投標人都有一個標有數字的牌子用於出價。拍賣師開始拍賣時，他觀察是否有牌子舉起出價。每次接受一個新的出價都改變了拍賣的當前價格，而且廣播給全部的投標人進行新的出價。

圖2 使用拍賣例子的觀察者模式
Observer 模式解說
下面經過一個例子來講明Observer模式。監控某一個公司的股票價格變化，能夠有多種方式，通知的對象能夠是投資者，或者是發送到移動設備，還有電子郵件等。一開始咱們先不考慮Observer模式，經過一步步地重構，最終重構爲Observer模式。如今有這樣兩個類：Microsoft和Investor，以下圖所示：
圖3 UML靜態圖示例
它們的實現以下：
public   class  Microsoft

 {
    private Investor _investor;

    private String _symbol;

    private double _price;


    public void Update()

    {
        _investor.SendData(this);
    }

    public Investor Investor

    {
        get { return _investor; }

        set { _investor = value; }
    }

    public String Symbol

    {
        get { return _symbol; }

        set { _symbol = value; }
    }

    public double Price
    {
        get { return _price; }

        set { _price = value; }
    }
}


public   class  Investor

 {
    private string _name;

    public Investor(string name)

    {
        this._name = name;
    }

    public void SendData(Microsoft ms)

    {
        Console.WriteLine("Notified {0} of {1}'s " + "change to {2:C}", _name, ms.Symbol,ms.Price);

    }

}
簡單的客戶端實現：
class  Program

 {

    static void Main(string[] args)

    {

        Investor investor = new Investor("Jom");

        Microsoft ms = new Microsoft();

        ms.Investor = investor;

        ms.Symbol = "Microsoft";

        ms.Price = 120.00;


        ms.Update();

        Console.ReadLine();

    }

}
運行後結果以下：
Notified Jom of Microsoft's change to ￥120
能夠看到，這段代碼運行並無問題，也確實實現了咱們最初的設想的功能，把Microsoft的股票價格變化通知到了Jom投資者那兒。可是這裏面出現了以下幾個問題：
1 ．Microsoft和Investor之間造成了一種雙向的依賴關係，即Microsoft調用了Investor的方法，而Investor調用了Microsoft類的屬性。若是有其中一個類變化，有可能會引發另外一個的變化。
2 ．當出現一種的通知對象，好比說是移動設備Mobile：
public   class  Mobile

 {
    private string _no;

    public Mobile(string No)

    {
        this._no = No;
    }

    public void SendData(Microsoft ms)

    {
        Console.WriteLine("Notified {0} of {1}'s " + "change to {2:C}", _no, ms.Symbol, ms.Price);

    }

}
這時候對應的 Microsoft的類就應該改變爲以下代碼，在 Microsot類中增長 Mobile，同時修改 Update()方法使其能夠通知到移動設備：
public   class  Microsoft

 {
    private Investor _investor;

    private Mobile _mobile;

    private String _symbol;

    private double _price;
 

    public void Update()

    {
        _investor.SendData(this);

        _mobile.SendData(this);
    }

 

    public Mobile Mobile

    {
        get { return _mobile; }

        set { _mobile = value; }
    }

    public Investor Investor

    {
        get { return _investor; }

        set { _investor = value; }
    } 

    public String Symbol

    {
        get { return _symbol; }

        set { _symbol = value; }
    }

    public double Price

    {
        get { return _price; }

        set { _price = value; }
    }

}
顯然這樣的設計極大的違背了「開放 -封閉」原則，這不是咱們所想要的，僅僅是新增長了一種通知對象，就須要對原有的 Microsoft類進行修改，這樣的設計是很糟糕的。對此作進一步的抽象，既然出現了多個通知對象，咱們就爲這些對象之間抽象出一個接口，用它來取消 Microsoft和具體的通知對象之間依賴。
圖4 靜態UML圖示例
實現代碼以下：
public   interface  IObserver

 {
    void SendData(Microsoft ms);
}

 

 public   class  Investor : IObserver

 {
    private string _name;

    public Investor(string name)

    {
        this._name = name;
    }

    public void SendData(Microsoft ms)

    {
        Console.WriteLine("Notified {0} of {1}'s " + "change to {2:C}", _name, ms.Symbol,ms.Price);

    }
}

public   class  Microsoft

 {
    private IObserver _investor;


    private String _symbol;

    private double _price;


    public void Update()

    {
        _investor.SendData(this);
    }

 

    public String Symbol

    {
        get { return _symbol; }

        set { _symbol = value; }
    }


    public double Price

    {
        get { return _price; }

        set { _price = value; }
    }


    public IObserver Investor

    {
        get { return _investor; }

        set { _investor = value; }
    }

}
作到這一步，能夠看到，咱們在下降二者的依賴性上已經邁進了一小步，正在朝着弱依賴性這個方向變化。在 Microsoft類中已經再也不依賴於具體的 Investor，而是依賴於接口 IObserver。
但同時咱們看到，再新出現一個移動設備這樣的通知對象，Microsoft類仍然須要改變，對此咱們再作以下重構，在Microsoft中維護一個IObserver列表，同時提供相應的維護方法。
圖5 靜態UML示例圖
Microsoft 類的實現代碼以下：
public   class  Microsoft

 {
    private List<IObserver> observers = new List<IObserver>();

    private String _symbol;

    private double _price;

    public void Update()

    {
        foreach (IObserver ob in observers)
        {
            ob.SendData(this);
        }

    }

    public void AddObserver(IObserver observer)

    {
        observers.Add(observer);
    }

    public void RemoveObserver(IObserver observer)

    {
        observers.Remove(observer);
    }

    public String Symbol

    {
        get { return _symbol; }

        set { _symbol = value; }
    }

    public double Price

    {
        get { return _price; }

        set { _price = value; }
    }

}
此時客戶端的調用代碼：
class  Program

 {
    static void Main(string[] args)

    {
        IObserver investor1 = new Investor("Jom");

        IObserver investor2 = new Investor("TerryLee");

        Microsoft ms = new Microsoft();

        ms.Symbol = "Microsoft";

        ms.Price = 120.00;

        ms.AddObserver(investor1);

        ms.AddObserver(investor2);

        ms.Update();

        Console.ReadLine();
    }
}
走到這一步，已經有了 Observer模式的影子了， Microsoft類再也不依賴於具體的 Investor，而是依賴於抽象的 IOberver。存在着的一個問題是 Investor仍然依賴於具體的公司 Microsoft，何況公司還會有不少 IBM， Google等，解決這樣的問題很簡單，只須要再對 Microsoft類作一次抽象。以下圖所示：
圖6 靜態UML示例圖
實現代碼以下：
public   abstract   class  Stock

 {
    private List<IObserver> observers = new List<IObserver>();

    private String _symbol;

    private double _price;

    public Stock(String symbol, double price)

    {
        this._symbol = symbol;

        this._price = price;
    }

    public void Update()

    {
        foreach (IObserver ob in observers)

        {
            ob.SendData(this);
        }

    }

    public void AddObserver(IObserver observer)

    {
        observers.Add(observer);
    }

    public void RemoveObserver(IObserver observer)

    {
        observers.Remove(observer);
    }

    public String Symbol

    {
        get { return _symbol; }
    }

    public double Price

    {
        get { return _price; }
    }
}

public   class  Microsoft : Stock

 {

    public Microsoft(String symbol, double price)

        : base(symbol, price)

    { }
}

public   interface  IObserver

 {
    void SendData(Stock stock);
}

public   class  Investor : IObserver

 {
    private string _name;

    public Investor(string name)

    {
        this._name = name;
    }

    public void SendData(Stock stock)

    {
        Console.WriteLine("Notified {0} of {1}'s " + "change to {2:C}", _name, stock.Symbol,stock.Price);

    }

}
客戶端程序代碼以下：
class  Program

 {
    static void Main(string[] args)

    {
        Stock ms = new Microsoft("Microsoft",120.00);

        ms.AddObserver(new Investor("Jom"));

        ms.AddObserver(new Investor("TerryLee"));

        ms.Update();

        Console.ReadLine();
    }

}
到這裏咱們能夠看到，經過不斷的重構，不斷地抽象，咱們由一開始的很糟糕的設計，逐漸重構爲使用 Observer模式的這樣一個方案。在這個例子裏面， IOberser充當了觀察者的角色，而 Stock則扮演了主題對象角色，在任什麼時候候，只要調用了 Stock的 Update()方法，它就會通知它的全部觀察者對象。同時能夠看到，經過 Observer模式，取消了直接依賴，變爲間接依賴，這樣大大提供了系統的可維護性和可擴展性。
推模式與拉模式
對於發佈-訂閱模型，你們都很容易能想到推模式與拉模式，用SQL Server作過數據庫複製的朋友對這一點很清楚。在Observer模式中一樣區分推模式和拉模式，我先簡單的解釋一下二者的區別：推模式是當有消息時，把消息信息以參數的形式傳遞（推）給全部觀察者，而拉模式是當有消息時，通知消息的方法自己並不帶任何的參數，是由觀察者本身到主體對象那兒取回（拉）消息。知道了這一點，你們可能很容易發現上面我所舉的例子實際上是一種推模式的Observer模式。咱們先看看這種模式帶來了什麼好處：當有消息時，全部的觀察者都會直接獲得所有的消息，並進行相應的處理程序，與主體對象沒什麼關係，二者之間的關係是一種鬆散耦合。可是它也有缺陷，第一是全部的觀察者獲得的消息是同樣的，也許有些信息對某個觀察者來講根本就用不上，也就是觀察者不能「按需所取」；第二，當通知消息的參數有變化時，全部的觀察者對象都要變化。鑑於以上問題，拉模式就應運而生了，它是由觀察者本身主動去取消息，須要什麼信息，就能夠取什麼，不會像推模式那樣獲得全部的消息參數。OK，說到這兒，你是否對於推模式和拉模式有了一點了解呢？我把前面的例子修改成了拉模式，供你們參考，能夠看到通知方法是沒有任何參數的：
public   abstract   class  Stock

 {
    private List<IObserver> observers = new List<IObserver>();

    private String _symbol;

    private double _price;

    public Stock(String symbol, double price)

    {
        this._symbol = symbol;

        this._price = price;
    }

    public void Update()

    {
        foreach (IObserver ob in observers)

        {
            ob.SendData();
        }
    }

    public void AddObserver(IObserver observer)

    {
        observers.Add(observer);
    }

    public void RemoveObserver(IObserver observer)

    {
        observers.Remove(observer);
    }

    public String Symbol

    {
        get { return _symbol; }
    }

    public double Price

    {
        get { return _price; }
    }
}

public   class  Microsoft : Stock

 {
    public Microsoft(String symbol, double price)

        : base(symbol, price)
    { }
}

public   interface  IObserver

 {
    void SendData();
}

public   class  Investor : IObserver

 {
    private string _name;

    private Stock _stock;

    public Investor(string name,Stock stock)

    {
        this._name = name;

        this._stock = stock;
    }

    public void SendData()

    {
        Console.WriteLine("Notified {0} of {1}'s " + "change to {2:C}", _name, _stock.Symbol, _stock.Price);

    }
}


class  Program

 {
    static void Main(string[] args)

    {
        Stock ms = new Microsoft("Microsoft", 120.00);

        ms.AddObserver(new Investor("Jom",ms));

        ms.AddObserver(new Investor("TerryLee",ms));

        ms.Update();

        Console.ReadLine();
    }

}
固然拉模式也是有一些缺點的，主體對象和觀察者之間的耦合增強了，可是這能夠經過抽象的手段使這種耦合關係減到最小。[感謝 idior的意見 ]
.NET 中的Observer模式
在.NET中，相信你們對於事件和委託都已經不陌生了，這裏就不具體多說了。利用事件和委託來實現Observer模式我認爲更加的簡單和優雅，也是一種更好的解決方案。由於在上面的示例中咱們能夠看到，雖然取消了直接耦合，可是又引入了沒必要要的約束（暫且這麼說吧）。即那些子類必須都繼承於主題父類，還有觀察者接口等。網上有不少這方面的例子，上面的例子簡單的用事件和委託實現以下，僅供你們參考：
class  Program
 {
    static void Main(string[] args)
    {
        Stock stock = new Stock("Microsoft", 120.00);

        Investor investor = new Investor("Jom");

        stock.NotifyEvent += new NotifyEventHandler(investor.SendData);

        stock.Update();

        Console.ReadLine();
    }
}

public   delegate   void  NotifyEventHandler( object  sender);


 public   class  Stock

 {
    public NotifyEventHandler NotifyEvent;

    private String _symbol;

    private double _price;

    public Stock(String symbol, double price)

    {
        this._symbol = symbol;

        this._price = price;
    }

    public void Update()

    {
        OnNotifyChange();    
    }

    public void OnNotifyChange()

    {
        if (NotifyEvent != null)

        {
            NotifyEvent(this);
        }

    }

    public String Symbol

    {
        get { return _symbol; }
    }

    public double Price

    {
        get { return _price; }
    }
}

 

 public   class  Investor

 {
    private string _name;

    public Investor(string name)

    {
        this._name = name;
    }

    public void SendData(object obj)

    {
        if (obj is Stock)

        {
            Stock stock = (Stock)obj;

            Console.WriteLine("Notified {0} of {1}'s " + "change to {2:C}", _name, stock.Symbol, stock.Price);
        }

    }

}
效果及實現要點
1 ．使用面向對象的抽象，Observer模式使得咱們能夠獨立地改變目標與觀察者，從而使兩者之間的依賴關係達到鬆耦合。
2 ．目標發送通知時，無需指定觀察者，通知（能夠攜帶通知信息做爲參數）會自動傳播。觀察者本身決定是否須要訂閱通知。目標對象對此一無所知。
3 ．在C#中的Event。委託充當了抽象的Observer接口，而提供事件的對象充當了目標對象，委託是比抽象Observer接口更爲鬆耦合的設計。
適用性
1 ．當一個抽象模型有兩個方面, 其中一個方面依賴於另外一方面。將這兩者封裝在獨立的對象中以使它們能夠各自獨立地改變和複用。
2 ．當對一個對象的改變須要同時改變其它對象, 而不知道具體有多少對象有待改變。
3 ．當一個對象必須通知其它對象，而它又不能假定其它對象是誰。換言之, 你不但願這些對象是緊密耦合的。
總結
經過Observer模式，把一對多對象之間的通知依賴關係的變得更爲鬆散，大大地提升了程序的可維護性和可擴展性，也很好的符合了開放-封閉原則。
參考資料
Erich Gamma 等，《設計模式：可複用面向對象軟件的基礎》，機械工業出版社
Robert C.Martin ，《敏捷軟件開發：原則、模式與實踐》，清華大學出版社
閻宏，《Java與模式》，電子工業出版社
Alan Shalloway James R. Trott ，《Design Patterns Explained》，中國電力出版社
MSDN WebCast 《C#面向對象設計模式縱橫談(19)：Observer 觀察者模式(行爲型模式)》
 
更多設計模式文章請訪問.NET設計模式系列
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程