IoC模式(轉)

IoC模式

1.依賴

依賴就是有聯繫，有地方使用到它就是有依賴它，一個系統不可能徹底避免依賴。若是你的一個類或者模塊在項目中沒有用到它，恭喜你，能夠從項目中剔除它或者排除它了，由於沒有一個地方會依賴它。下面看一個簡單的示例：

    /// <summary> /// 用戶播放媒體文件 /// </summary> public class OperationMain {

 public void PlayMedia() { MediaFile _mtype = new MediaFile(); Player _player = new Player(); _player.Play(_mtype); } } /// <summary> /// 播放器 /// </summary> public class Player { public void Play(MediaFile file) { Console.WriteLine(file.FilePath); } } /// <summary> /// 媒體文件 /// </summary> public class MediaFile { public string FilePath { get; set; } }

上面是一個用戶用播放器播放文件簡單示例，用戶操做是OperationMain類中的PlayMedia方法，打開一個播放器，選擇一個文件來播放。先看看他們之間的依賴關係，能夠簡單找到有3個依賴

1. Player依賴MediaFile
2. OperationMain依賴Player
3. OperationMain依賴MediaFile

2.依賴倒置

需求增長了，要用不一樣的播放器，播放不一樣的文件，咱們要抽象出來，減小耦合。

耦合關係就是依賴關係，若是依賴關係至關繁雜，牽一髮而動全身，很難維護；依賴關係越少，耦合關係就越低，系統就越穩定，因此咱們要減小依賴。

幸好Robert Martin大師提出了面向對象設計原則----依賴倒置原則： 　　

• A. 上層模塊不該該依賴於下層模塊，它們共同依賴於一個抽象。 　
• B. 抽象不能依賴於具象，具象依賴於抽象。

理解：A.上層是使用者，下層是被使用者，這就致使的結果是上層依賴下層了，下層變更了，天然就會影響到上層了，致使系統不穩定，甚至是牽一髮而動全身。那怎麼減小依賴呢？就是上層和下層都去依賴另外一個抽象，這個抽象比較穩定，整個就來講就比較穩定了。

B.面向對象編程時面向抽象或者面向藉口編程，抽象通常比較穩定，實現抽象的具體確定是要依賴抽象的，抽象不該該去依賴別的具體，應該依賴抽象。

 

上面播放器的示例中，咱們已經找到依賴關係了，如今咱們要按照依賴倒置原則，來進行優化。

根據原則以下改動：

• Player依賴MediaFile，好辦，讓Player和MediaFile都去依賴一個抽象IMediaFile
• OperationMain依賴Player，好辦，讓OperationMain和Player都依賴一個抽象IPlayer
• OperationMain依賴MediaFile，好辦，讓OperationMain和MediaFile都依賴一個抽象IMediaFile
• IPlayer不能依賴具體MediaFile，應該依賴於具體MediaFile的抽象IMediaFile

結構很簡單，因而代碼大體以下：

    /// <summary> /// 用戶播放媒體文件 /// </summary> public class OperationMain {

 public void PlayMedia() { IMediaFile _mtype = new MediaFile(); IPlayer _player = new Player(); _player.Play(_mtype); } } /// <summary> /// 播放器 /// </summary> public interface IPlayer { void Play(IMediaFile file); } /// <summary> /// 默認播放器 /// </summary> public class Player : IPlayer { public void Play(IMediaFile file) { Console.WriteLine(file.FilePath); } } /// <summary> /// 媒體文件 /// </summary> public interface IMediaFile { string FilePath { get; set; } } /// <summary> /// 默認媒體文件 /// </summary> public class MediaFile : IMediaFile { public string FilePath { get; set; } }

上面代碼進行了抽象，能夠看到，目的是減小了依賴，可是看上去依賴關係增長了，如用戶PlayMedia方法，依賴還增長了依賴接口和具體的實現，可是接口是穩定的，能夠不考慮，具體的實現纔是變更的，這個依賴仍是要的，要播放文件，一定要用到具體的播放器和具體文件。

3.控制反轉(IoC)

現實生活中，是具體的播放器和具體的媒體文件沒有關係，你給它一個Mp3文件他能夠播放，給它一個Mp4文件它也能夠播放，你刪掉你的媒體文件，播放器照樣在，具體什麼播放器，播放什麼文件，控制權所有是咱們用戶本身。

上面的示例中基本實現了隔離，具體的播放器跟具體的媒體隔離了，具體的播放器只跟媒體接口和播放器接口有關。可是PlayMedia的方法裏面的具體對象，寫死了，控制權很是小，若是我想用百度影音播放呢，我想換一首音樂呢，只能從新改代碼，那控制怎麼進行轉移呢？

咱們能夠經過反射來建立，把具體的文件名寫在配置文件裏，這時候客戶端代碼也不用變了，只須要改配置文件就行了，穩定性又有了提升，以下：

        public void PlayMedia() { IMediaFile _mtype = Assembly.Load(ConfigurationManager.AppSettings["AssemName"]).CreateInstance(ConfigurationManager.AppSettings["MediaName"]); IPlayer _player = Assembly.Load(ConfigurationManager.AppSettings["AssemName"]).CreateInstance(ConfigurationManager.AppSettings["PlayerName"]); _player.Play(_mtype); }

這個具對象是哪個，全由配置文件來控制了，這個具體對象的控制權交給了配置文件了，這也是人們常說的控制反轉。

控制反轉IoC是Inversion of Control的縮寫，是說對象的控制權進行轉移，轉移到第三方，好比轉移交給了IoC容器，它就是一個建立工廠，你要什麼對象，它就給你什麼對象，有了IoC容器，依賴關係就變了，原先的依賴關係就沒了，它們都依賴IoC容器了，經過IoC容器來創建它們之間的關係。

4.依賴注入(DI)

上面說到控制反轉，是一個思想概念，可是也要具體實現的，上面的配置文件也是一種實現方式。依賴注入提出了具體的思想。

依賴注入DI是Dependency Injection縮寫，它提出了「哪些東東的控制權被反轉了，被轉移了？」，它也給出了答案：「依賴對象的建立得到被反轉」。

所謂依賴注入，就是由IoC容器在運行期間，動態地將某種依賴關係注入到對象之中。

上面的示例中，哪些要依賴注入，依賴對象須要得到實例的地方，即 PlayMedia方法，須要IPlayer具體對象和IMediaFile的具體對象，找到了地方就從這裏下手，爲了靈活的控制這兩個對象，必須是外面可以控制着兩個對象的實例化，提供對外的操做是必要的，能夠是屬性，能夠是方法，能夠是構造函數，總之別的地方能夠控制它，下面將會使用Unity來注入，使用的是構造函數注入，代碼以下：

    /// <summary> /// 用戶播放媒體文件 /// </summary> public class OperationMain { IMediaFile _mtype; IPlayer _player; public OperationMain(IPlayer player, IMediaFile mtype) { _player = player; _mtype = mtype; } public void PlayMedia() { _player.Play(_mtype); } } /// <summary> /// 播放器 /// </summary> public interface IPlayer { void Play(IMediaFile file); } /// <summary> /// 默認播放器 /// </summary> public class Player : IPlayer { public void Play(IMediaFile file) { Console.WriteLine(file.FilePath); } } /// <summary> /// 媒體文件 /// </summary> public interface IMediaFile { string FilePath { get; set; } } /// <summary> /// 默認媒體文件 /// </summary> public class MediaFile : IMediaFile { public string FilePath { get; set; } }

給 OperationMain類一個構造函數，由於Unity有一個構造函數注入，調用代碼以下：

        static UnityContainer container = new UnityContainer(); static void init() { container.RegisterType<IPlayer, Player>(); container.RegisterType<IMediaFile, MediaFile>(); } static void Main(string[] args) {  init(); OperationMain op1 = container.Resolve<OperationMain>(); op1.PlayMedia(); OperationMain op3 = container.Resolve<OperationMain>(); op3.PlayMedia(); //普通方式 OperationMain op2 = new OperationMain(new Player(), new MediaFile()); op2.PlayMedia(); Console.Read(); }

看出來吧，Unity的功能遠不止這些，你能夠初始化時註冊N多，之後直接使用，而不用使用new，還有實例週期的控制、配置文件等靈活控制，具體能夠看看Unity（具體不是本節的範疇）的說明。

5.小結

經過一個小例子由淺入深地進行優化，已加深對IoC模式的理解，我想複雜的結構也是從這種簡單的架構累加起來的。

最近在看相關文章，不少都太專業化了沒怎麼看懂，這是本身如今對IoC的一些理解，記錄下來，要否則時間一久，也就忘了。

本身對IoC模式理解還很淺，但願獲得各位的指點。

 

做者：Qlin
出處：http://www.cnblogs.com/qqlin/
本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，不然保留追究法律責任的權利。

原文：http://www.cnblogs.com/qqlin/archive/2012/10/09/2707075.html