在《手撕JAVA（四）低依赖架构思想》一文中阐述了如何通过依赖倒置来解耦，并且得到了结论这种架构思想的落地实现就是Spring。很多有一定J2EE开发经验的读者读到此处会反驳，依赖倒置其实就是遵循了面向接口编程的思想，Spring的核心组件IOC并不是面向接口编程啊，它管理的还是一个一个的类。
在解答这个疑惑之前，顺带提个题外话——面向接口编程。
很多人在初学JAVA，尤其是计算机专业的学生，老师都会讲到JAVA中面向接口编程会为程序带来很多灵活性。如何理解老师讲的这句话？我们不妨来想想，依赖倒置降低依赖，就是建立在面向接口编程带来的可以方便切换实现类而程序其他地方感知不强烈这一优点上。
接下来解释一下笔者为什么说spring就是依赖倒置思想的落地实现？
确实，Spring的核心IOC，其实本质上就是一个容器，而这个容器里面都是管理的一个个JAVA类，和本质上是面向接口编程的依赖倒置思想扯不上什么直接关系。但为什么笔者明明知道这个结论一眼下去看似是错的还要这样说喃？其实之所以说Spring是依赖倒置思想的落地实现是因为Spring的核心——IOC，就是在整个思想落地实现过程中为了解决某些问题而设计出来的一个组件。
虽然Spring的设计理念和依赖倒置思想没有直接关系，但是确实是因为有了依赖倒置思想的落地实现过程才诞生了Spring！！！其实真正和依赖倒置思想面向接口解耦这一逻辑直接相关的是现在Spring体系中常用的分层逻辑——controller、service+Impl、Mapper（如果是其他持久化框架，此处就是其他类型的dao，此处以mapper为例）。
做过spring体系开发的读者应该很快就能理解到笔者上面说的话，controller、service+Impl、Mapper层层之间的依赖关系是严格按照依赖倒置思想来落地实现的。
读到此处很多很多读者也许会问，这里也没有spring什么事情啊，我不用spring，在controller中直接new serviceImpl也可以啊。
那我们为什么要设计出Spring？它在整个依赖倒置思想落地实现的过程中的作用到底是什么？
好的，下面三张图来解释两个问题，弄懂了这两个问题也就彻底明白了现在流行的分层，原因到底是什么？Spring到底为什么被设计出来。就会彻底明白Spring和解耦之间的关系！
1、为什么要用service+Impl，而不直接使用Impl？
2、Spring到底是为了什么而设计出来的？
图1、直接依赖于Impl
图2、依赖于Service
图3、Spring容器介入
解释三张图：
图1：①依赖度太高，不便于切换。②自己去new，内存管理混乱
图2：①采用依赖倒置的思想，降低依赖度，切换方便。②内存管理依旧混乱。
图3：面向接口、降低依赖；容器介入，管理内存。
