依赖倒置原则（DIP）、控制反转（IoC）、依赖注入（DI）（C#）

理解：

依赖倒置原则（DIP）主程序要依赖于抽象接口，不要依赖于具体实现。高层模块不应该依赖底层模块，两个都应该以来抽象。抽象不应该依赖细节，细节应该依赖抽象。（具体看我上一篇贴子）

依赖倒置原则是六大设计原则中的一种，它的大致意思是所有模块都应该依赖于抽象，而不是直接依赖于另一个模块。依赖倒置原则仅仅只是一个原则而已，它只是告诉了你程序应该要变成什么样子（模块之间依赖抽象），而并没有具体告诉你应该怎么做。就像是在学校，老师告诉你教室要干净，不要有垃圾，而具体打扫垃圾的动作老师却并没有告诉你，你可以选择用扫把打扫，也可以选择用手捡，但是最终教室要干净（当然，你也可以不遵守）。

控制反转（IoC）就是遵循了依赖倒置原则的一个思想。

什么是控制？控制就是对对象进行创建、操作、销毁。

什么是“反转”（叫“转移”更为贴切）？“反转”的意思就是将“控制”的操作交由外部来处理，自己只管用，只管要，其他的都不管。

为什么说控制反转遵循了依赖倒置原则？虽然A模块需要B模块，但是A模块中并不是声明了B模块对象的引用，而是声明了对IB（B模块抽象）的引用，A模块真正需要的是实现了IB抽象的子类，所以A模块并不依赖于B模块，而是依赖于IB抽象。

控制反转的大意为：如果模块A需要模块B，模块A中并不是直接控制创建模块B，而是从外部控制如何创建。例如我们将创建何种对象的控制权交由配置文件控制，然后根据配置文件中的信息（程序集+类型），通过反射来获取对象，而不是直接new对象，这也是控制反转的一种体现。

IoC容器会连接程序中的所有模块，模块将所需对象的控制权都交由IoC容器控制，IoC容器会根据用户配置的信息将各个模块所需要的对象事先创建完成，然后IoC容器可以通过依赖注入（DI）的方式为模块注入所需对象（还有依赖查找（DL）），依赖注入就是一种具体实现的手段。

依赖倒置原则、控制反转和依赖注入并不是为程序带来新的功能，而是使得程序中模块的耦合性降低，提高每个模块的复用性。

举个栗子：

就拿生活中最常见的自助取款机来说一下，首先我们要拥有一张银行卡，例如建设银行的银行卡CCBCard类（设计的一些属性可能不太合理，不过重要的是了解思想）

//建行银行卡
public class CCBCard
{
    //银行卡中的钱
    public decimal Money { get; set; }

    //银行卡名字
    public String Name { get; set; }

    public CCBCard(decimal money,String name)
    {
        this.Money = money;
        this.Name = name;
    }
}

然后我们来创建一个ATM自动取款机类，该取款机拥有取钱和存钱的功能

ATM机1.0

//自动取款机
public class ATM
{
    //建行银行卡
    public CCBCard Card = new CCBCard(1000,"建行卡");

    //取钱
    public void SubMoney(decimal money)
    {
        //判断余额是否足够
        if (Card.Money >= money)
        {
            //取钱
            this.Card.Money -= money;
            Console.WriteLine($"取钱成功，余额{Card.Money}");
        }
        else {
            Console.WriteLine("余额不足");
        }
    }

    //存钱
    public void AddMoney(decimal money)
    {
        //存钱
        this.Card.Money += money;
    }
}

因为这个例子是生活中非常常见的，所以大家肯定一眼就看出了不妥

此时的ATM机可是说是个非常“睿智”的ATM机了，我去取钱，而ATM机却自带了一张建行银行卡，与其说是个ATM机，倒不如说只能对一个CCBCard建行卡进行存取的机器。此时ATM类完全依赖于CCBCard对象，而且CCBCard对象也是由ATM类创建的，如果CCBCard修改了，或者要换其他的卡，ATM机还要做出修改。

所以接下来我们应该将这不好的两点改掉：

1、ATM机只能读取单一的CCBCard卡（ATM控制CCBCard对象的创建）

2、ATM只能读取CCBCard类型的卡（ATM完全依赖于CCBCard对象）

先来解决第一点，接下来我们改进一下，为ATM机增加构造函数，通过构造函数传递CCBCard对象，使得ATM机可以操作其他建行卡：

ATM机2.1：

增加构造函数，两个方法不用变

//建行银行卡
public CCBCard Card;

//构造函数传入CCBCard对象
public ATM(CCBCard card)
{
    this.Card = card;
}

使用：

//银行卡
CCBCard card = new CCBCard(1000,"建行卡");
//ATM
ATM atm = new ATM(card);
//取钱
atm.SubMoney(100);

 然后来解决第二个问题，只能存取建行卡：

此时就需要用到依赖倒置原则，让ATM类依赖于CCBCard抽象，而不是具体的实现。如果我们想存取其他银行卡里面的钱，必须为所有的银行卡抽象出一个接口，然后让所有银行卡子类都实现这个接口。

//银行卡接口
public interface ICard
{
    string Name { get; set; }
    decimal Money { get; set; }
}

建行卡实现该接口：

//建行银行卡
public class CCBCard:ICard
{
    //银行卡中的钱
    public decimal Money { get; set; }

    //银行卡名字
    public String Name { get; set; }

    public CCBCard(decimal money,String name)
    {
        this.Money = money;
        this.Name = name;
    }
}

使得ATM机依赖于ICard接口(修改了Card属性和构造函数)，而且ATM机并不控制ICard的子类，而是将控制权交由调用者。这一切才合情合理啊，无论用户插入什么卡，该ATM机都能进行存取。这就是控制反转，而通过构造函数传入的ICard对象则是通过依赖注入的方式注入对象。

//建行银行卡
public ICard Card;

//构造函数传入ICard对象（依赖注入）
public ATM(ICard card)
{
    this.Card = card;
}

依赖注入还有其他两种：通过接口和属性注入

//属性注入
public ICard Card { get; set; }

//接口注入
//该方法实现了接口
public void Inject(ICard card)
{
    this.Card = card;
}

而接口注入就是通过方法注入，此种方式会增加不必要的接口，现在基本不使用，大多为构造函数注入。

新添加一个ICBC（工商银行）卡进行测试

//工商银行卡
public class ICBCCard : ICard
{
    public string Name { get; set; }
    public decimal Money { get; set; }
}

测试：

//建设银行卡
CCBCard bcard = new CCBCard(1000, "CCB");
//工商银行卡
ICBCCard ccard = new ICBCCard()
{
    Money = 1000,
    Name = "ICBC"
};

//ATM
ATM atm1 = new ATM(bcard);
ATM atm2 = new ATM(ccard);
//取钱
atm1.SubMoney(100);

IoC容器就是专门为ATM机这种模块服务的，它就像是一个大齿轮一样，连接所有小齿轮（模块），它运转，整个程序便运转，如果有些模块可能需要用到其他模块中的对象，它们并不会直接依赖，而是全都由IoC容器控制。

虽然互相需要，但是互不依赖，IoC容器会事先将ICard子类创建好，然后通过依赖注入注入到ATM机中（Unity、Spring.NET等框架都是封装完善的IoC容器），ATM机只管接收，只管索取。ATM机是不对子类进行创建的，控制权在用户手里，由用户控制ATM机操作何种银行卡，就像你去取钱一样，你插入什么卡自助取款机都可以取钱，这看起来是多么平常的一件事？很多看起来高大上的思想，都是从需求演变过来的，然后由前人一点点探索研究总结出来。

至此ATM机已经完成了，可能因为ATM机太常见了，所以我所说的一切你都可以想到（换卡，换不同银行的银行卡），就像是在说废话，如果你都理解了，那么根据ATM机，你应该仔细的思索一下，你所设计的类和模块满不满足像ATM机一样的“功能”？