本篇介绍软件设计原则之一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 ；欢迎您的关注
