設(shè)計模式——監(jiān)控服務(wù)定位器

　　監(jiān)控服務(wù)定位器模式是控制反轉(zhuǎn)模式的一種實現(xiàn)方式，它通過一個稱為服務(wù)定位器的外部組件來為需要依賴的組件提供依賴。服務(wù)定位器有時是一個具體的接口，為特定服務(wù)提供強類型的請求；有時它又可能是一個泛型類型，可以提供任意類型的請求服務(wù)。
　　1.強類型服務(wù)定位器
　　在本例中，當(dāng)需要一個實現(xiàn)了IMessaginService接口的對象時，我們知道應(yīng)該調(diào)用GetMessagingService方法。該方法返回一個IMessagingService接口對象，因此，我們不需要轉(zhuǎn)換結(jié)果的類型。
　　上面的示例是將監(jiān)控服務(wù)定位器作為一個接口，而不是一個具體的類型。我們的目標是降低組件之間的耦合性，其中包括消費者代碼和服務(wù)定位器之間的耦合。如果消費者代碼實現(xiàn)了IServiceLocator接口，我們就可以在運行時環(huán)境中選擇合適的實現(xiàn)方式。
　　上面的代碼假設(shè)每個創(chuàng)建Notification System實例的人都會訪問服務(wù)定位器。這樣做帶來的方便是，如果應(yīng)用程序通過服務(wù)定位器創(chuàng)建Notification System實例，那么定位器可以傳遞它本身到Notification System類的構(gòu)造函數(shù)中；如果是在服務(wù)定位器的外部創(chuàng)建Notification System類的實例，那么我們還需要提供服務(wù)定位器到Notification System類的實現(xiàn)，以便服務(wù)定位器找到它的依賴項。
　　但是有些時候我們有更多的理由選擇不使用服務(wù)定位器。首先，服務(wù)定位器僅限于創(chuàng)建那些在IServiceLocator接口設(shè)計時已經(jīng)預(yù)先知道的類型對象，而不能創(chuàng)建其他類型的對象；其次，當(dāng)應(yīng)用程序中的服務(wù)增加時，就不得不持續(xù)地擴展IServiceLocator接口的定義，而這將加重應(yīng)用程序維護擴展的負擔(dān)。
　　2.弱類型服務(wù)定位器
　　如果在某個具體應(yīng)用中，強類型監(jiān)控服務(wù)定位器的負面影響超過了它所帶來的正面效應(yīng)，我們可以考慮使用弱類型服務(wù)定位器。服務(wù)定位器模式的這種變體跟家靈活，因為它允許請求任意的服務(wù)類型。之所以稱之為弱類型服務(wù)定位器，是因為它采用Type類型的參數(shù)，并返回一個非類型化的實例，也就是一個Object類型的對象。顯然，我們需要把調(diào)用Get Service方法返回的結(jié)果轉(zhuǎn)換為相應(yīng)類型的對象。
　　該方法的負面影響是，它強制IServiceLocator接口必須實現(xiàn)兩個幾乎一樣的方法，而不是只實現(xiàn)一個。這些無謂的努力在NET3.5中被移除，因為3.5版本中引入了一個新特性：擴展方法。擴展方法作為靜態(tài)類的靜態(tài)方法來編寫，在它的第一個參數(shù)中利用特殊的this關(guān)鍵字來指定擴展方法要附加到的類型。
　　3.服務(wù)定位器的利與弊
　　服務(wù)定位器的用法相對來說比較簡單：我們先從某個地方得到服務(wù)定位器，然后利用定位器查找依賴。我們可能在一個已知的（全局）位置找到服務(wù)定位器，或者通過我們的創(chuàng)建者獲得服務(wù)定位器。盡管依賴關(guān)系有時會發(fā)生改變，但是簽名不會改變，因為查找依賴唯一需要的就是定位器。
　　持久簽名帶來好處的同時，也帶來了弊端。它導(dǎo)致了組件需求的不透明性：使用組件的開發(fā)人員通過查看構(gòu)造函數(shù)的簽名不能知道服務(wù)要求的是什么，這使得他們不得不查看那些可能過期的文檔，或者干脆傳遞一個空服務(wù)定位器來查看我們請求的內(nèi)容。