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