[轉]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模式理解還很淺，希望得到各位的指點。

 

[轉]IoC模式