程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> .NET網頁編程 >> 關於.NET >> .NET設計模式(19):觀察者模式(Observer Pattern)

.NET設計模式(19):觀察者模式(Observer Pattern)

編輯:關於.NET

概述

在軟件構建過程中,我們需要為某些對象建立一種“通知依賴關系” ——一個對象(目標對象)的狀態發生改變,所有的依賴對象(觀察者對象)都將得到通知。如果這樣的依賴關系過於緊密,將使軟件不能很好地抵御變化。使用面向對象技術,可以將這種依賴關系弱化,並形成一種穩定的依賴關系。從而實現軟件體系結構的松耦合。

意圖

定義對象間的一種一對多的依賴關系,當一個對象的狀態發生改變時, 所有依賴於它的對象都得到通知並被自動更新。[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模式,把一對多對象之間的通知依賴關系的變得更為松散,大大地提高了程序的可維護性和可擴展性,也很好的符合了開放-封閉原則。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved