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模式。