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個依賴

Player依賴MediaFile

OperationMain依賴Player

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

轉載于:https://www.cnblogs.com/lsgsanxiao/p/4615534.html

總結

以上是生活随笔為你收集整理的IoC模式(转)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。