设计模式-原则篇（依赖倒置原则 DIP）

概念

三层概念：

• 高层模块不依赖低层模块，两者都应该依赖其抽象
• 抽象不应该依赖细节
• 细节应该依赖抽象

解读

高层模块和底层模块：对于计算机程序来说，不管是站在架构的角度，还是站在一个代码开发的角度，为了将系统结构化管理，都会将整个结构通过层级进行管理。下层结构为上层结构提供服务，上层服务会通过下游调用的服务进行业务逻辑的扩展。比如为了实现网络传输能力，将整个网络传输过程分成iso七层体系（物理层、数据链路层、网络层、传输层、会话层、表现层、应用层）。这里上层结构就是高层模块、下层结构就是底层模块。

高层模块不依赖低层模块：这里上层模块不依赖下层模块，指的是高层服务不应该依赖底层模块的具体实现，应该依赖其约定的契约。

抽象不应该依赖细节：具体接口的契约，不应该依赖于具体的实现，契约应该是根据系统结构功能来设计。

细节应该依赖抽象：具体的细节实现应该按照抽象的契约来完成。

优缺点

优点：

• 依赖倒置可以将上下层级的依赖关系解耦，上层不会依赖于具体的下层实现细节，程序整体结构设计更灵活

缺点：

• 依赖倒置会引入抽象契约模块，整个程序的结构会复杂，但是对于小型项目来说，其实收益不是很大，依赖倒置的优势是在处理大型系统的复杂逻辑，对于系统逻辑模块的扩展收益很大，但是对于小型项目会导致结构复杂。

例子

家里的空调最近坏了，修理工师傅过来检查到的毛病是空调的控温主板坏了，通过置换新的空调的控温主板进行修复。控温主板主要提供空调温度控制，同时控温主版不仅仅支持海尔空调其他空调也支持。

这里海尔空调属于高层模块，空调不仅仅需要涉及控温主办，还设计排气模块、显示模块等。控温主板属于底层模块，主要负责温度控制 。可以替换新的控温主板来提升空调的能力，但是新的控温主板实现细节，是需要依赖于控温主板接口。

思考

依赖倒置主要的作用就是解耦上下游依赖关系，如果关系不是强依赖，对于之后的替换、升级不会影响整个上层业务逻辑。同时如果每个模块能够解耦，则可以分开开发，实现并行开发，对于项目的整体进度能达到提升的结果。