Spring源码解析（一）开篇

前言

　　Spring源码继承结构比较复杂，看过以后经常会忘记。因此，记录一下源码分析的过程，方便以后回顾。本次分析的Spring源码版本为3.2.15。

　　另外，一提Spring就是IOC、DI等等，我们先初步了解一下这些概念。

依赖倒置原则（Dependence Inversion Principle）：面向对象设计原则的一种(抽象概念)，其他的还有单一职责原则、里氏替换原则、接口隔离原则、依赖倒置原则、迪米特原则、开-闭原则。

控制反转（Inversion Of Control）：它是遵循依赖倒置原则设计的一种设计模式或者说设计思想（还是停留在概念），所谓控制反转其实就是依赖对象的获取权被反转了，不再由自己控制，而是由第三方来控制。

依赖注入（Dependency Injection）：依赖注入是实现控制反转（设计思想）的一种具体实现方式。

依赖倒置原则（DIP）

依赖倒置原则

A.高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。

B.抽象不应该依赖于具体实现，具体实现应该依赖于抽象。

 

举个简单例子理解一下：

public class ServiceA{
    private ServiceB serviceB;//ServiceB是一个接口
    
    public  void toDoMethod(){
        serviceB.toDo();
    }
    
    public ServiceA(){
        this.serviceB=new ServiceBImpl1();
    }
}

什么是高层次的模块依赖于低层次的模块?

　　ServiceA需要调用ServiceB的服务，在ServiceA的构造方法里创建了ServiceB的实现ServiceBImpl1，这就是高层次模块（ServiceA）依赖了底层模块（依赖了具体实现：ServiceBImpl1），这种依赖就有个问题，如果调用ServiceA是根据不同场景需要调用ServiceB不同的实现怎么办呢？所以这种依赖具体实现的方式就导致ServiceA与ServiceB的具体实现耦合太高，ServiceA没法做成一个通用组件。

public class ServiceA{
    private ServiceB serviceB;//ServiceB是一个接口
    
    public  void toDoMethod(){
        serviceB.toDo();
    }
}

什么是依赖倒置呢？

　　如上代码所示，ServiceA中并没有ServiceB具体实现，也就是所谓的ServiceA依赖了ServiceB的抽象。在编译期ServiceA（.高层次的模块）并没有依赖低层次模块(ServiceB的具体实现)，只有真正在运行期需要ServiceB实现的时候才会有交集，这就大大降低耦合度。

控制反转（Inversion Of Control）

 依赖倒置原则只是告诉我们不要依赖具体实现，要依赖抽象。它只是指导思想，具体怎么去实现呢？控制反转就是在指导思想下设计出的一套解决方案。

高层次模块中只依赖低层次模块的抽象(接口或抽象类)，创建低层次模块具体对象的事情不再由高层次模块负责，而是交由第三方来完成，在运行期需要的时候再通过某种方式获得低层次模块的实现。

到此，还是只停留在理论层面。

依赖注入（Dependency Injection）

IoC是一个很大的概念，可以用不同的方式来实现。其主要实现方式有两种：<1>依赖查找（Dependency Lookup）：容器提供回调接口和上下文环境给组件。EJB和Apache Avalon都使用这种方式。<2>依赖注入（Dependency Injection）：组件不做定位查询，只提供普通的Java方法让容器去决定依赖关系。后者是时下最流行的IoC类型，其又有接口注入（Interface Injection），设值注入（Setter Injection）和构造子注入（Constructor Injection）三种方式。

依赖注入是现在最主流的方式。因为它太主流，导致现在ioc已经约等于DI。

IOC容器

我们提到创建依赖对象的工作由第三方来完成，这个第三方就是IOC容器，它负责理清模块与模块直接的依赖关系，并且负责进行依赖注入。

当然，这个容器要做的足够灵活、可配置。

总结

依赖倒置是指导思想

　　　　反转控制是解决方案

　　　　　　　　依赖注入是一种具体实施

IOC的优点：

　　1.模块与模块直接耦合度降低，这样有利于团队协作开发、单元测试。

　　2.面向接口编程，系统灵活性增加。

　　3.模块直接的复杂依赖关系、对象的创建以及生命周期管理等都有容器完成。

IOC的缺点：

　　1.原本简单通过new就可以完成的对象创建，现在需要一个复杂过程来完成。

　　2.面向接口编程，灵活度增强了必然导致效率的降低。

所以说，IOC这种模式不是适合所有的系统，还是要根据系统特点来选择是否需要IOC模式。