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/