Observer模式深度探索
|
微軟頂級技術大師Jeffrey Richter的作品，一向是不容錯過的。為了幫助開發者這篇專論Observer模式的文章也不例外。Observer模式是經典設計模式中應用最為廣泛也最為靈活多變的模式之一。本文在.NET技術框架下深入發掘了Observer模式的內涵，值得細細品味。
雖然設計模式并不是萬能丹，但確實是一個非常強大的工具，開發人員或架構師可使用它積極地參與任何項目。設計模式可確保通過熟知和公認的解決方案解決常見問題。模式存在的事實基礎在于：大多數問題，可能已經有其他個人或開發小組解決過了。因此，模式提供了一種在開發人員和組織之間共享可使用解決方案的形式。無論這些模式的出處是什么，這些模式都利用了大家所積累的知識和經驗。這可確保更快地開發正確的代碼，并降低在設計或實現中出現錯誤的可能性。此外，設計模式在工程小組成員之間提供了通用的術語。參加過大型開發項目的人員都知道，使用一組共同的設計術語和準則對成功完成項目來說是至關重要的。最重要的是，如果能正確地使用，設計模式可以節省您大量的時間。
.NET框架模式
雖然GoF的示例僅限于C++和Smalltalk，但設計模式并不與特定語言或開發平臺捆綁在一起；Microsoft .NET框架的出現為分析設計模式提供了新的機會和環境。在框架類庫(FCL)的開發過程中，Microsoft應用了很多GoF模式。由于.NET框架中提供的功能范圍非常廣泛，因此，還開發和提出了一些全新的模式。
我們對設計模式的研究從Observer模式入手。
Observer模式
面向對象的開發的一個主導原則是，在給定的應用程序中正確地劃分任務。系統中的每個對象應該將重點放在問題域中的離散抽象上。簡而言之，一個對象只應做一件事，而且要將它做好。這種方法可確保在對象之間劃定清晰的界限，因而可提供更高的重用性和系統可維護性。
一個特別重要的領域是用戶界面和基礎業務邏輯之間的交互。在應用程序的開發過程中，需要快速更改用戶界面，并且不能對應用程序的其他部分產生連帶影響，這是司空見慣的事。此外，業務要求也可能會發生變化，而這一切與用戶界面無關。具有豐富開發經驗的人都知道，在很多情況下，這兩組要求都會發生變化。如果沒有劃分UI和應用程序其他部分，修改任一部分都會對整體造成不利的影響。
很多應用程序都需要在用戶界面和業務邏輯之間劃分清晰的界限。因此，自GUI出現以后，很多面向對象的框架均支持將用戶界面從應用程序的其他部分中劃分出來。其中的大部分應用程序采用的設計模式幾乎相同。這種模式通常稱為觀察者，它非常有助于在系統中各種對象之間劃分清晰的界限。此外，還會經常看到在框架或應用程序中與UI無關的部分中使用這種解決方案。Observer模式的作用遠遠超過了其最初的想法。
邏輯模型
雖然Observer模式有很多變體，但該模式的基本前提包含兩個角色：觀察者(observer)和主體(subject)（熟悉Smalltalk MVC的人將這些術語分別稱為View和Model）。在用戶界面的環境中，觀察者是負責向用戶顯示數據的對象。另一方面，主體表示從問題域中模擬的業務抽象。正如圖1中所描述的一樣，在觀察者和主體之間存在邏輯關聯。當主體對象中發生更改時，（例如，修改實例變量），觀察者就會觀察這種更改，并相應地更新其顯示。
例如，假定我們要開發一種簡單的應用程序，來跟蹤全天的股票價格。在此應用程序中，我們指定一個Stock類來模擬在NASDAQ交易的各種股票。該類包含一個實例變量，它表示在全天不同時段經常波動的股價。為了向用戶顯示此信息，應用程序使用一個StockDisplay類向stdout（標準輸出）寫信息。在此應用程序中，一個Stock類實例作為主體，一個StockDisplay類實例作為觀察者。隨著股價在交易日中隨時間發生變化，Stock實例的當前股價也會發生變化（它怎樣變化并不重要）。因為StockDisplay實例正在觀察Stock實例，所以在這些狀態發生變化（修改股價）時，就會向用戶顯示這些變化。
通過使用這種觀察過程，可以在Stock和StockDisplay類之間劃分界限。假定應用程序的要求第二天發生變化，要使用基于窗體的用戶界面。要啟用此新功能，只需要構造一個新類StockForm作為觀察者。無論發生什么情況，Stock類都不需要進行任何修改。事實上，它甚至不知道發生此類更改。類似地，如果需求變化要求Stock類從另一個來源檢索股價信息（可能是從Web服務，而不是從數據庫中檢索），則StockDisplay類不需要進行修改。它只是繼續觀察Stock就夠了。
物理模型
正如大多數解決方案一樣，問題在于細節。Observer模式也不例外。雖然邏輯模型規定觀察者觀察主體；但在實現這種模式時，這實際上是一個名稱誤用。更準確地說，觀察者向主體注冊，表明它觀察主體的意愿。在某種狀態發生變化時，主體向觀察者通知這種變化情況。當觀察者不再希望觀察主體時，觀察者向主體撤消注冊。這些步驟分別稱為觀察者注冊、通知和撤消注冊。
大多數框架通過回調來實現注冊和通知。圖2、3和4中所示的UML序列圖模擬這種方法通常使用的對象和方法調用。對于不熟悉序列圖的人來說，最上面的矩形框表示對象，而箭頭表示方法調用。
圖2描述了注冊序列。觀察者對主體調用Register方法，以將其自身作為參數傳遞。在主體收到此引用后，它必須將其存儲起來，以便在將來某個時間狀態發生變化時通知觀察者。大多數觀察者實現并非將觀察者引用直接存儲在實例變量中，而是將此任務委托給一個單獨的對象（通常為一個容器）。使用容器來存儲觀察者實例可提供非常大的好處，我們將對它進行簡要介紹。
圖3突出顯示了通知序列。當狀態發生變化時（AskPriceChanged），主體通過調用Get觀察者s方法來檢索容器中的所有觀察者。主體然后枚舉檢索的觀察者，并調用Notify方法以通知觀察者所發生的狀態變化。
圖4顯示撤消注冊序列。此序列是在觀察者不再需要觀察主體時執行的。觀察者調用UnRegister方法，并將其自身作為參數進行傳遞。然后，主體對容器調用Remove方法以結束觀察過程。
回到我們的股票應用程序，讓我們分析一下注冊和通知過程所產生的影響。在應用程序啟動過程中，一個StockDisplay類實例注冊到Stock實例中，并將其自身作為參數傳遞到Register方法。Stock實例（在容器中）保存對StockDisplay實例的引用。當股價屬性發生變化時，Stock實例通過調用Notify方法向StockDisplay通知所發生的變化。在應用程序關閉時，StockDisplay實例使用以下方法撤消注冊Stock實例：調用UnRegister方法，終止兩個實例之間的關系。
請注意利用容器（而不是使用實例變量）來存儲觀察者引用有什么優點。假定除當前用戶接口StockDisplay外，我們還需要繪制股價在交易日內變化的實時圖形。為此，我們創建了一個名為StockGraph的新類，它繪制股價（y軸）和當天時間（x軸）的圖形。在應用程序啟動時，它同時在Stock實例中注冊StockDisplay和StockGraph類的實例。因為主體在容器（與實例變量相對）中存儲觀察者，所以這不會出現問題。當股價發生變化時，Stock實例向其容器中的兩個觀察者實例通知所發生的狀態變化。正如我們所看到的一樣，使用容器可提供更大的靈活性，即每個主體可支持多個觀察者。這使主體有可能向無數多個觀察者通知所發生的狀態變化，而不是只通知一個觀察者。
雖然不是強制要求，但很多框架為觀察者和主體提供了一組要實現的接口。正如下面的C#代碼示例所示，IObserver接口公開一種公共方法Notify。此接口是由所有要用作觀察者的類實現的。IObservable接口（是由所有要用作主體的類實現的）公開兩種方法Register和UnRegister。這些接口通常采用抽象虛擬類或真實接口的形式（如果實現語言支持此類構造的話）。利用這些接口有助于減少觀察者和主體之間的耦合關系。與觀察者和主體類之間的緊密耦合關系不同，IObserver和IObservable接口允許執行獨立于實現的操作。通過對接口的分析，您將注意到鍵入的所有方法針對的是接口類型（與具體類相對）。這種方法將接口編程模型的優點擴展到Observer模式。
IObserver和IObservable接口(C#)
| //interface the all observer classes should implement public interface IObserver { void Notify(object anObject); }//IObserver //interface that all observable classes should implement public interface IObservable { void Register(IObserver anObserver); void UnRegister(IObserver anObserver); }//IObservable |
再回到我們的示例應用程序，我們知道Stock類用作主體。因此，它將實現IObservable接口。類似地，StockDisplay類實現IObserver接口。因為所有操作都是由該接口定義的（而不是由具體類定義的），所以Stock類并未與StockDisplay類綁定在一起，反之亦然。這使我們能夠快速地更改特定的觀察者或主體實現，而不會影響應用程序的其他部分（使用不同的觀察者替換StockDisplay或添加額外的觀察者實例）。
除了這些接口外，框架還經常為主體提供一個通用基類，減少了支持Observer模式所需的工作。基類實現IObservable接口，以提供支持觀察者實例存儲和通知所需的基礎結構。下面的C#代碼示例簡要介紹一個名為ObservableImpl的基類。盡管可能任何容器都可以完成這一任務，但該類在Register和UnRegister方法中將觀察者存儲委托給哈希表實例（為了方便起見，我們在示例中使用哈希表作為容器，它只使用一個方法調用來撤消注冊特定的觀察者實例）。還要注意添加了NotifyObservers方法。此方法用于通知哈希表中存儲的觀察者。在調用此方法時，將枚舉該容器，并對觀察者實例調用Notify方法。
ObservableImpl類(C#)
| //helper class that implements observable interface public class ObservableImpl:IObservable { //container to store the observer instance (is not synchronized for this example) protected Hashtable _ObserverContainer=new Hashtable(); //add the observer public void Register(IObserver anObserver){ _ObserverContainer.Add(anObserver,anObserver); }//Register //remove the observer public void UnRegister(IObserver anObserver){ _ObserverContainer.Remove(anObserver); }//UnRegister //common method to notify all the observers public void NotifyObservers(object anObject) { //enumeration the observers and invoke their notify method foreach(IObserver anObserver in _ObserverContainer.Keys) { anObserver.Notify(anObject); }//foreach }//NotifyObservers }//ObservableImpl |
我們的示例應用程序使用以下方法來利用此基類基礎結構：修改Stock類以擴展ObservableImpl類，而不是提供其自己的特定IObservable接口實現。因為ObservableImpl類實現了IObservable接口，所以不需要對StockDisplay類進行任何更改。實際上，這種方法簡化了Observer模式的實現，在保持類之間松散耦合關系的同時，使多個主體重復使用相同的功能。
下面的.NET觀察者示例重點說明了IObservable和IObserver接口以及ObservableBase類在我們的股票應用程序中的使用情況。除了Stock和StockDisplay類外，此示例使用MainClass將觀察者和主體實例關聯起來，并修改Stock實例的AskPrice屬性。此屬性負責調用基類的NotifyObservers方法，而該方法又向該實例通知相關的狀態變化。
觀察者示例(C#)
| //represents a stock in an application public class Stock:ObservableImpl { //instance variable for ask price object _askPrice; //property for ask price public object AskPrice { set { _askPrice=value; base.NotifyObservers(_askPrice); }//set }//AskPrice property }//Stock //represents the user interface in the application public class StockDisplay:IObserver { public void Notify(object anObject){ Console.WriteLine("The new ask price is:" + anObject); }//Notify }//StockDisplay public class MainClass{ public static void Main() { //create new display and stock instances StockDisplay stockDisplay=new StockDisplay(); Stock stock=new Stock(); //register the grid stock.Register(stockDisplay); //loop 100 times and modify the ask price for(int looper=0;looper < 100;looper++) { stock.AskPrice=looper; } //unregister the display stock.UnRegister(stockDisplay); }//Main }//MainClass |
.NET框架中的Observer模式
基于我們對Observer模式的了解，讓我們將注意力轉向此模式在.NET框架中的使用情況。您們當中非常熟悉FCL中所公開類型的人將會注意到，框架中沒有IObserver、IObservable或ObservableImpl類型。雖然您的確可以在.NET應用程序中使用這些構造，但引入委托和事件可提供新的、功能強大的方法來實現Observer模式，而不必開發專用于支持該模式的特定類型。事實上，因為委托和事件是CLR的一級成員，所以將此模式的基本構造添加到.NET框架的核心中。因此，FCL在其結構中廣泛使用Observer模式。
介紹委托和事件內部工作方式的文章非常多，我們在此不再贅述。我們只需說明委托是面向對象（和類型安全）版的函數指針就夠了。委托實例保存對實例或類方法的引用，允許匿名調用綁定方法。事件是在類上聲明的特殊構造，可在運行時發布被關注對象的狀態變化。事件表示我們前面用于實現Observer模式的注冊、撤消注冊和通知方法的形式抽象（CLR和多種不同的編譯器對它提供支持）。委托是在運行時注冊到特定事件中的。在引發事件時，將調用所有注冊的委托，以使它們能夠收到事件的通知。
按照Observer模式定義的術語，聲明事件的類就是主體。與我們以前使用的IObservable接口和ObservableImpl類不同，主體類不需要實現給定接口或擴展基類。主體只需要公開一個事件，而不需要執行任何其他操作。觀察者創建的工作略多一些，但靈活性卻提高得非常多（我們將在后面討論）。觀察者并不實現IObserver接口和將其自身注冊到主體中，而是必須創建特定的委托實例，并將此委托注冊到主體事件中。觀察者必須使用具有事件聲明所指定類型的委托實例，否則，注冊就會失敗。在創建此委托實例的過程中，觀察者將傳遞該主體向委托通知的方法（實例或靜態）名稱。在將委托綁定到方法后，可以將其注冊到主體的事件中。類似地，也可以從事件中撤消注冊此委托。主體通過調用事件向觀察者提供通知。
如果您不熟悉委托和事件，則實現Observer模式似乎需要做很多工作，尤其是與我們以前使用的IObserver和IObservable接口相比。但是，它比聽起來要簡單一些，并且實現起來要容易得多。下面的C#和Visual Basic .NET代碼示例重點說明了在我們的示例應用程序中支持委托和事件所需的類修改。注意，沒有Stock或StockDisplay類用于支持該模式的任何基類或接口。
使用委托和事件的觀察者(C#)
| public class Stock { //declare a delegate for the event public delegate void AskPriceDelegate(object aPrice); //declare the event using the delegate public event AskPriceDelegate AskPriceChanged; //instance variable for ask price object _askPrice; //property for ask price public object AskPrice { set { //set the instance variable _askPrice=value; //fire the event AskPriceChanged(_askPrice); } }//AskPrice property }//Stock class //represents the user interface in the application public class StockDisplay { public void AskPriceChanged(object aPrice) { Console.Write("The new ask price is:" + aPrice + ""); } }//StockDispslay class public class MainClass { public static void Main(){ //create new display and stock instances StockDisplay stockDisplay=new StockDisplay(); Stock stock=new Stock(); //create a new delegate instance and bind it //to the observer's askpricechanged method Stock.AskPriceDelegate aDelegate=new Stock.AskPriceDelegate(stockDisplay.AskPriceChanged); //add the delegate to the event stock.AskPriceChanged+=aDelegate; //loop 100 times and modify the ask price for(int looper=0;looper < 100;looper++) { stock.AskPrice=looper; } //remove the delegate from the event stock.AskPriceChanged-=aDelegate; }//Main }//MainClass |
在熟悉了委托和事件后，您就會清楚地看到它們的巨大潛力。與IObserver和IObservable接口以及ObservableImpl類不同，使用委托和事件可大大減少實現此模式所需的工作量。CLR和編譯器為觀察者容器管理提供了基礎，并且為注冊、撤消注冊和通知觀察者提供了一個通用調用約定。也許，委托的最大優點是其能夠引用任何方法的固有特性（條件是它符合相同的簽名）。這允許任何類用作觀察者，而與它所實現的接口或它專用的類無關。雖然使用IObserver和IObservable接口可減少觀察者和主體類之間的耦合關系，但使用委托可完全消除這些耦合關系。
事件模式
基于事件和委托，FCL可以非常廣泛地使用Observer模式。FCL的設計者充分認識到此模式的巨大潛力，并在整個框架中將其應用于用戶界面和非UI特定的功能。但是，用法與基本Observer模式稍有不同，框架小組將其稱為事件模式。
通常，將此模式表示為事件通知進程中所涉及的委托、事件和相關方法的正式命名約定。雖然CLR或標準編譯器并沒有強制要求利用事件和委托的所有應用程序和框架都采用這種模式，但Microsoft建議這樣做。
其中的第一條約定也可能是最重要的約定是主體公開的事件的名稱。對于它所表示的狀態變化而言，此名稱應該是不言自明的。切記，此約定以及所有其他此類約定本身就是主觀性的。目的是為那些利用您的事件的人員提供清晰的說明。事件模式的其他部分利用正確的事件命名，因而此步驟對模式來說至關重要。
回到我們的示例，讓我們分析一下這種約定對Stock類產生的影響。派生事件名稱的適當方法是，利用在主體類中修改的字段的名稱作為根。因為在Stock類中修改的字段名稱是_askPrice，所以合理的事件名稱應該是AskPriceChanged。很明顯，此事件的名稱比StateChangedInStockClass等具有更強的描述性。因此，AskPriceChanged事件名稱符合第一條約定。
事件模式中的第二條約定是正確命名委托及其簽名。委托名稱應該包含事件名稱（通過第一個約定選擇的）及附加詞Handler。此模式要求委托指定兩個參數，第一個參數提供對事件發送方的引用，第二個參數向觀察者提供環境信息。第一個參數的名稱就是sender。必須將此參數鍵入為System.Object。這是由于以下事實：可能將委托綁定到系統中任何類上的任何潛在方法。第二個參數的名稱（甚至比第一個參數更簡單）為e。必須將此參數鍵入為System.EventArgs或某種派生類（有時比此內容還多）。雖然委托的返回類型取決于您的實現需要，但大多數實現此模式的委托根本不返回任何值。
需要稍加注意委托的第二個參數e。此參數允許主體對象將任意環境信息傳遞給觀察者。如果不需要此類信息，則使用System.EventArgs實例就足夠了，因為此類的實例表示沒有環境數據。否則，應該使用相應的實現構造從System.EventArgs派生的類以提供此數據。必須按照具有附加詞EventArgs的事件名稱來命名該類。
請參考我們的Stock類，此約定要求將處理AskPriceChanged事件的委托命名為AskPriceChangedHandler。此外，應該將此委托的第二個參數命名為AskPriceChangedEventArgs。因為我們需要將新的股價傳遞給觀察者，所以我們需要擴展System.EventArgs類，以將該類命名為AskPriceChangedEventArgs并提供實現來支持傳遞此數據。
事件模式中的最后一個約定是負責引發事件的主體類上方法的名稱和可訪問性。此方法的名稱應該包含事件名稱以及添加的On前綴。應該將此方法的可訪問性設置為保護。此約定僅適用于非密封（在VB中不可繼承）類，因為它作為派生類調用在基類中注冊的觀察者的已知的調用點。
將此最后一條約定應用于Stock類，即可完成事件模式。因為Stock類不是密封的，所以我們必須添加一種方法來引發事件。按照該模式，此方法的名稱為OnAskPriceChanged。下面的C#代碼示例顯示應用于Stock類的事件模式的完整視圖。請注意我們的System.EventArgs類的專門用法。
事件模式示例(C#)
| public class Stock { //declare a delegate for the event public delegate void AskPriceChangedHandler(object sender, AskPriceChangedEventArgs e); //declare the event using the delegate public event AskPriceChangedHandler AskPriceChanged; //instance variable for ask price object _askPrice; //property for ask price public object AskPrice { set { //set the instance variable _askPrice=value; //fire the event OnAskPriceChanged(); } }//AskPrice property //method to fire event delegate with proper name protected void OnAskPriceChanged() { AskPriceChanged(this,new AskPriceChangedEventArgs(_askPrice)); }//AskPriceChanged }//Stock class //specialized event class for the askpricechanged event public class AskPriceChangedEventArgs:EventArgs { //instance variable to store the ask price private object _askPrice; //constructor that sets askprice public AskPriceChangedEventArgs(object askPrice) { _askPrice=askPrice; } //public property for the ask price public object AskPrice { get { return _askPrice; } } }//AskPriceChangedEventArgs |
結論
基于這里對Observer模式的分析，我們可以清楚地看到此模式提供了一個完美的機制，能夠在應用程序中的對象之間劃定清晰的界限。雖然通過回調進行實現（使用IObserver和IObservable接口）相當簡單，但CLR的委托和事件概念可處理大多數“繁重的工作”，并降低主體和觀察者之間的耦合級別。實際上，通過正確地使用此模式，在確保應用程序可演變性方面就會向前邁出一大步。當您的UI和業務要求隨時間發生變化時，Observer模式可確保能夠簡化您的工作。
在開發靈活的應用程序方面，設計模式是一個非常強大的工具（如果有效地加以運用）。撰寫本文是為了說明模式方法的有效性，并重點說明.NET框架中使用的一種模式。將來的文章將繼續探究FCL中的模式，并簡要介紹一些用于生成有效Web服務的模式。