关于IOC的思考

1.依赖源码

依赖就是有联系，有地方使用到它就是有依赖它，一个系统不可能完全避免依赖。如果你的一个类或者模块在项目中没有用到它，恭喜你，可以从项目中剔除它或者排除它了，因为没有一个地方会依赖它。下面看一个简单的示例：

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

3.控制反转(IoC)

现实生活中，是具体的播放器和具体的媒体文件没有关系，你给它一个Mp3文件他可以播放，给它一个Mp4文件它也可以播放，你删掉你的媒体文件，播放器照样在，具体什么播放器，播放什么文件，控制权全部是我们用户自己。

上面的示例中基本实现了隔离，具体的播放器跟具体的媒体隔离了，具体的播放器只跟媒体接口和播放器接口有关。但是PlayMedia的方法里面的具体对象，写死了，控制权非常小，如果我想用百度影音播放呢，我想换一首音乐呢，只能重新改代码，那控制怎么进行转移呢？

我们可以通过反射来创建，把具体的文件名写在配置文件里，这时候客户端代码也不用变了，只需要改配置文件就好了，稳定性又有了提高，如下：

public void PlayMedia()
{
    IMediaFile mtype = (IMediaFile)Assembly.Load(ConfigurationManager.AppSettings["AssemName"]).CreateInstance(ConfigurationManager.AppSettings["MediaName"]);
    IPlayer player = (IPlayer)Assembly.Load(ConfigurationManager.AppSettings["AssemName"]).CreateInstance(ConfigurationManager.AppSettings["PlayerName"]);

    if (player != null) 
        player.Play(mtype);
}
App.config
<appSettings>
  <add key="AssemName" value="IOC"/>
  <add key="MediaName" value="IOC.MediaFile"/>
  <add key="PlayerName" value="IOC.Player"/>
</appSettings>

这个具对象是哪一个，全由配置文件来控制了，这个具体对象的控制权交给了配置文件了，这也是人们常说的控制反转。

控制反转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)
    {
        StackTrace ss = new StackTrace(true);
        _player = player;
        _mtype = mtype;
        mtype.FilePath = ss.GetFrame(1).GetMethod().ToString();
    }

    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有一个构造函数注入，调用代码如下：

class Program
{
    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();
    }
}