依赖注入，控制反转（设计模式）

控制反转IOC

看下边的代码

public class UserServiceTest {
    public static boolean doTest() {
    // ...
    }
    public static void main(String[] args) {// 这部分逻辑可以放到框架中
    if (doTest()) {
      System.out.println("Test succeed.");
    } else {
      System.out.println("Test failed.");
    }
  }
}

　　

在上边的代码中所有的流程都是由程序控制，如果我们抽象出下面的一个框架，我们在来看如何利用框架来实现同样的功能。 具体代码如下： 

public abstract class TestCase {
    public void run() {
        if (doTest()) {
            System.out.println("Test succeed.");
        } else {
            System.out.println("Test failed.");
        }
    }
    public abstract void doTest();
}
public class JunitApplication {
    private static final List<TestCase> testCases = new ArrayList<>();
    public static void register(TestCase testCase) {
        testCases.add(testCase);
    }
    public static final void main(String[] args) {
        for (TestCase case: testCases) {
            case.run();
        }
    }
}

　　

刚刚举的这个例子，即使典型的同构框架来实现控制反转的例子，框架提供了一个可扩展的代码的骨架，用来组装对象，管理这个执行路程。程序利用框架及逆行开发的时候，只需要往预留点上扩展，添加跟自己业务相关的代码。就可以利用这个框架来驱动整个程序的流程的执行。这里的控制是指的是对程序流程的控制。使用框架之后，整个程序的执行流程通过框架来控制，流程的控制从程序员反转到框架。 

实际上，实现控制反转的方法很多，除了刚才例子中所展示的类似与模板设计的方法之外。 还有马上讲到的依赖注入等方法，所以，控制反转并不是一种具体的实现技巧，而是比较笼统的设计思想，一般用于指导框架层面的设计。 

依赖注入 DI 

接下来，我们在来看依赖注入，依赖注入和控制反转恰恰相反，它是一种具体的编码技巧。依赖注入的英文翻译Dependency Injection 。缩写为DI 。对于这个感念，有一个非常形象的说法，那就是：依赖注入是一个标价25元，实际上只值5分的概念。也就是说这恶概念听起来高大上，实际上理解和应用起来非常简单。 

那到底什么是依赖注入？ 我们用一句话来概括，不用new （） 方法在类的内部创建依赖对象，而是讲依赖的对象在外部创建好之后，通过构造函数，函数参数等方式注入给类使用。 

通过依赖注入的方式讲依赖的对象传递进来，这样就提高了代码的扩展性，我们可以灵活地替换依赖的类。这一点我们在讲开闭原则的时候提到过。当然上面的代码还有继续优化的空间，我们还可以把MessageSender 定义为接口，基于接口而非实现的编程。 

依赖注入框架

在实际的软件开发中，一些项目可能会涉及几十，上百甚至几百个类，类对象的篡改就和依赖注入会变得非常的复杂。如果这部分工作又程序员来完成。容易出错且成本也比较高。而对象的创建和依赖注入工作，本身和业务没有关系。 我们完全可以抽象成框架来自动完成， 

依赖反转原则

它的具体的含义是高层模块不要依赖底层模块。高层模块和底层模块应该通过抽象来互相依赖。出吃之外抽象不要依赖细节，细节依赖抽象。这条原则，主要色hi用来指导框架层面的设计的。