SOLDI原则之DIP：依赖倒置原则

本篇介绍软件设计原则之一DIP：依赖倒置原则。不少知识回头来看会有新的理解。看到一句话，一段文字，一个观点有了新的理解，醍醐灌顶的感受。这种感受像是一种惊喜。古语说：温故而知新。

DIP：依赖倒置原则

a.高层模块不该该依赖于低层模块。两者都应该依赖于抽象。

b.抽象不该该依赖于细节。细节应该依赖于抽象。

层次化

Booch曾经说过：“全部结构良好的面向对象架构都具备清晰的层次定义，每一个层次经过一个定义良好的、受控的接口向外提供了一组内聚的服务”

倒置的接口全部权

这里的倒置不只仅是依赖关系的倒置，它也是接口全部权的倒置。咱们一般会认为工具库应该拥有它们本身的接口。可是当应用了DIP时，咱们发现每每是客户拥有抽象接口，而它们的服务者从这些抽象接口派生。

依赖于抽象

该启发式规则建议不该该依赖于具体类——也就是说应该终止于抽象类或接口。

咱们在应用程序中所编写的大多数的类是不稳定的。咱们不想直接依赖于这些不稳定的具体类。经过把它们隐藏在抽象接口的后面，能够隔离它们的不稳定性。但这不是一个完整的解决方案，经常，若是一个不稳定的接口必需要变化时，这个变化必定会影响到表示该类的接口。这种变化仍是破坏了由抽象接口维系的隔离性。若是看得更远一些，认为是由客户模块或层来声明它们须要的服务接口，那么仅当客户须要时才会对接口进行改变。这样，改变实现抽象接口的类就不会影响到客户。

那么咱们来聊下咱们应用中经常使用的架构类型，微软为了展现.Net企业系统开发的能力。曾经发布过一个PetShop做为范例，后来不少企业系统的架构都采用了参照了或简化了此架构设计。标准的三层架构。

 

从上图所知，业务层对数据访问层抽象出来的IDAL模块，除了解除了向下的依赖以外，对于其上的业务逻辑层，相同仅存在弱依赖关系。那么来看这个设计知足了DIP：依赖倒置原则的高层模块不该该依赖于低层模块，两者都应该依赖于抽象。 传统的软件开发，好比结构化分析和设计，老是倾向于建立一些高层模块依赖于低层模块、策略依赖于细节的软件结构。实际上这些方法的目的之一就是要定义子程序层次结构，该层次结构描述了高层模块怎么调用低层模块。一个设计良好的面向对象程序（如上图所示的Petshop ),其依赖程序结构至关于传统的过程式方法设计的一般结构而言就是被“倒置“了。

那么IDAL接口层的全部权属于谁的？之前一直有这个疑问直到看到这一章疑问解决了。一般认为IDAL接口层属于DAl层，那是不对的。这里的IDAL接口层的全部权是属于BLL层了，接口全部权倒置了。经过倒置这些依赖关系，咱们建立了一个更灵活、更持久、更易改变的结构。高层模块BLL不在直接依赖DAL层，而依赖抽象IDAL接口层。则层与层之间的关系就是松散耦合的。假设此时必需要改动数据访问层的实现，仅仅从新实现IDAL的接口定义，那么业务逻辑层就不会受到影响。毕竟，不管是SQLServerDAL仍是OracalDAL与业务逻辑层实现没有直接的关系。

面象对象的程序设计倒置了依赖关系，使得细节和策略依赖于抽象，而且经常是客户拥有服务接口。依赖关系的倒置正是好的面向对象设计的标志所在。是实现许多面向对象技术所宣称的好处的基本低层机制。它的正确应用对于建立重用的框架来讲是必需的。同时它对于构建在变化面前富有弹性也是重要的。因为抽象和细节彼此隔离，因此代码也很是容易维护。

其实最深的体会是对接口全部权倒置的理解。

代码示例地址：https://github.com/tianyaxiang/ApplicationArchitecture

本文首发于我的微信公众号：webguan ；欢迎您的关注