依赖反转原则 DIP, Dependency inversion principle
- 高层模块不应该依赖于低层模块。二者都应该依赖于抽象
- 抽象不应该依赖于细节。细节应该依赖于抽象
高低层
首先理解一下什么高层和低层
高层
高层包含了一个应用程序中的重要策略选择和业务模型
也就是业务逻辑是高层
低层
相对于高层，低层包括框架、数据库、消息队列等其它系统部分
这也符合我们的预期，不管数据库，还是框架改变时，不应该影响到业务逻辑；也就是说业务逻辑不应该依赖于具体实现技术细节
反转
反转想起了IOC，之前总结了一篇《IOC理解》
DIP里面指的反转是什么？
这是一个典型的调用树例子，main函数调用了一些高层函数，这些高层函数又调用了一些中层函数，中层函数继续调用低层函数。源代码层面的依赖不可避免地要跟随程序的控制流
这造成了程序耦合性特别的高，若程序需要改变实现方式，那就是灾难，也违反了OCP
也导致了在软件架构上别无选择。系统行为决定了控制流，而控制流则决定了源代码依赖关系
有这么多的问题，怎么办呢？ 反转
反转依赖方向
如何达到呢？利用面向对象的多态特性，这是面向对象编程的好处，也是面向对象的核心本质，无论面向怎么样的源代码级别的依赖关系，都可以将其反转
控制流是从高层到低层，但低层模块与接口抽象类的方向正好相反
面向对象编程就是以多态为手段来对源代码中的依赖关系进行控制能力
架构师可以完全采用面向对象系统中所有源代码依赖关系，而不再受到系统控制流的限制。不管哪个模块调用或者被调用，架构师都可以随意更改源代码依赖关系
业务逻辑控制用户界面与数据库，但源代码依赖关系相反，这样业务逻辑模块的源代码不需要引入用户界面和数据库两个模块，于是业务逻辑组件就可以独立于用户界面和数据库独立部署，不会对业务逻辑产生任何影响
反转：控制流方向与源代码依赖关系方向相反，源代码依赖方向永远是控制流方向的反转
分层
延伸一下DIP，探讨一下分层架构
架构模式有很多种，分层、六边形等等，分层架构是运用最为广泛的架构模式
为什么要分层
虽然分层架构很流行，尤其常用的MVC，但为什么需要分层呢？
对系统的结构分层，把系统中相关联的部分被集中放在一个独立的层内，分而治之，这正好是SRP，每一层只能有一个引起他变化的原因
如何分层呢？变化原因可以有多个维度
一、基于关注点,如MVC，其上面向用户的体验与交互，中间面向应用与业务逻辑，其下面向各种外部资源与设备
二、基于变化，针对不同变化原因确定层次边界，如数据库结构的修改自然会影响到基础设施的数据模型以及领域层的领域模型，但当我们仅修改数据库访问实现时，就不应该影响到领域层
不管以何种原因将软件切割成不同的层，至少有一层是只包含该软件的业务逻辑的，而用户接口、系统接口则属于其他层
源码中的依赖关系必须只指向同心圆的内层，即由低层机制指向高层策略
Entities业务实体：封装了整个系统的关键业务逻辑，一个业务实体既可以是一个带有方法的对象，也可以是一组数据结构和函数集合。
如果我们写的不是一个大型系统，而是一个单一应用的话，那么我们的业务实体就是该应用的业务对象。这些对象封装了该应用中最通用、最高层的业务逻辑
而分层也不必为经典的三层架构又或是DDD的四层的固有思维，而是将分层视为关注点分离的水平抽象层次的体现。层太少可能导致关注点不够分离，导致系统的结构不合理；层太多则引入太多的间接而增加不必要的开支
层协作
在固有认知中，分层架构的依赖都是自顶向下传递的
比如：Controller依赖Service，Service依赖Dao;如此控制流决定了源代码的依赖关系，也就是没有反转，是违背DIP的
从DIP定义，为什么要依赖抽象呢？除了能反转从而解耦，还有别的原因吗？
我们每次修改接口时，一定会去修改实现；但修改实现时不一定修改接口；也就是抽象比实现稳定，抽象层相对是个稳定的层次；抓住不变的，控制住变化的，是我们的目标，优秀工程师就得多花时间在设计接口上，减少未来对其改动，争取在不修改接口的情况下增加新功能
其实除了自顶向下的请求也有自底向上的通信：通知，观察者模式，在上层定义Observer接口，提供update()方法供下层在感知状态发生变更时高用
层与层之间的协作，就得借助DIP，打破高层依赖低层的固有思维，从解除耦合的角度探索层之间可能的协作关系，再配合IOC，具体依赖关系由IOC框架实现，更好地解除了高层对低层的依赖
实践
- 在代码中多使用抽象接口，尽量避免使用那些多变的具体实现类
- 不要在具体实现类上创建子类
- 不要override包含具体实现的函数
- 应避免在代码中写入与任何具体实现相关的名字，或者是其它容易变动的事物的名字
