//司机源代码
public class Driver{
    public void drive(Benz benz){
        benz.run();
    }
}

//奔驰车源代码
public class Benz{
    public void run(){
        System.out.println("奔驰汽车开始运行....");
    }
}

//场景类源代码
public class Client{
    public static void main(String[] args){
        Driver siji = new Driver(); //实例一个司机对象。
        Benz benz = new Benz(); //实例一个奔驰车对象。
        sji.drive(benz); //司机开着奔驰车跑了起来。
    }
}

//定义司机接口，可能会有张三司机、李四司机
public interface IDriver{
    //是司机就应该会驾驶汽车
    public void drive(ICar car);
}

//定义汽车接口，可能有宝马、奔驰
public interface ICar{
    //是汽车都应该能跑
    public void run();
}

//司机的实现类
public class Driver implements IDriver{
    public void drive(ICar car){
        car.run();
    }
}

//奔驰汽车的实现类
public class Benz implements ICar{
    public void run(){
        System.out.println("奔驰汽车....");
    }
}

//宝马汽车的实现类
public class BMW implements ICar{
    public void run(){
        System.out.println("宝马汽车....");
    }
}

//场景类
public class Client{
    public static void main (String[] args){
        IDriver zhangshan = new Driver();
        ICar benz = new Benz();
        ICar bmw = new BMW();
        //张三开奔驰
        zhangshan.drive(benz);
        //张三开宝马
        zhangshan.drive(bmw);
    }
}

---- 概念 ----

◆1.依赖倒置原则（DIP，Dependency Inverse Principle）
    强调系统的高层组件不应当依赖于底层组件；并且不论是高层组件还是底层组件都应当依赖于抽象。

◆2.依赖（Dependency）
    组件A如果：①.持有B的引用，②调用B的方法，③创建（new）B，则A对B产生依赖

◆3.控制（Control）
    A依赖B，则B拥有“控制权”，因为B的某种变化可能会引起A的变化

◆4.控制反转（IoC，Inverse of Control）
    就是将控制方“往高处/上层”转移
    控制反转是实现依赖倒置的一种方法

◆5.依赖注入（DI，Dependency Injection）
    组件通过构造函数或者setter方法，将其依赖暴露给上层；上层要设法取得组件的依赖，并将其传递给组件。
    依赖注入是实现控制反转的一种手段

---- DIP，DI与IoC 不得不说的故事 ----

“高层组件不应当依赖于低层组件；并且不论是高层组件还是低层组件都应当依赖于抽象！”
                              —— DIP

于是，按照DIP说的，我们把底层组件抽象为接口与实现类，高层组件依赖此接口。看起来，大家都是依赖抽象了，不过，我们应该在何处、如何取得具体的底层组件实例？？

1.通过底层组件工厂（纯虚构），将"new"操作"集中起来管理"。于是高层组件对底层组件的依赖转变为了对"纯虚构"出来的工厂的依赖（这就是IoC的一种实现手段）。新的问题来了，其实工厂也是不小的麻烦。
（地点：高层组件内部；方式：通过底层组件工厂）

2.高层组件咆哮到：“底层组件和工厂都TM伤不起！动不动就变！！有木有！！我不管了啊！要调用我的组件们，我给你们开放注入具体实现的接口（构造函数注入，setter/getter注入），你们自己看着办啊 ！！！”——于是，依赖注入（DI）的基础建立了起来，同时，对依赖关系的管理任务也交给了上层（这就是IoC的一种实现手段）。
（地点：高层组件的使用者内部；方式：设法取得具体实现，并传递给高层组件）

2.5 高层组件的高层组件无语了，但是它很淡定地如法炮制，将这个“麻烦”交给了它的高层组件，and so on...最终，最高处的那个组件（一般它叫“应用”），表示鸭梨非常大：“你们把所有的依赖都转给我了？！？！这不是坑爹吗？”

3.此时，"工厂"的角色和范畴扩大，它接纳了“管理整个应用的所有实现类对象”的任务。它通过某种方式（比如Spring的XML配置方式、注解方式；Guice的编程方式）向应用提供了管理组件之间依赖关系的接口，于是，应用所要考虑的所有依赖关系都可以委托给这样的"工厂"了，"工厂"成为了应用唯一依赖 —— 整个应用的“控制权”全都由具体实现（包括底层组件具体实现、甚至底层组件工厂等）反转至了"工厂"的依赖接口中，“IoC容器”是它响亮的新名字！
（地点：IoC容器；方式：通过IoC容器的API）

4.IoC容器的引入，让整个应用变得十分灵活，组件之间可以“热插拔”。这也正是DIP的初衷。

 * 通过IoC容器，我们在使用一个组件时，需要指定它的依赖，以及它的依赖的依赖...and so on，这形成了一个“对象图”的概念