浅谈依赖倒置原则
框架和工具的区别
我们工作中经常用到优秀的框架和工具，他们为什么优秀，知其然了其精髓能对我们起到更多的帮助。好的框架应该让使用者感受不到他的存在，而能为其提供很多的功能。客户程序在框架内可以任意实现自己的业务逻辑代码， 而好的框架应该完全能支持才对。这就是工具和框架的区别，工具是为客户提供了某些能力，客户去主动调用，而框架是为客户程序提供了一种固有模式约束，由客户程序来按照约定好的的模式逻辑来实现，框架把按照框架架构所约束的模式实现的所有程序统一提供了框架所具有的功能支持。
从上可以看出，框架和工具的主要区别是在框架中客户程序把实现的具体控制权上交上去了，使具有高层决定性作用的框架功能不会依赖于客户程序的实现。这就是我们今天的正题了依赖倒置。
依赖倒置
Hollywood原则？什么是依赖倒置
引用<<敏捷软件开发>>中一言，一个设计良好的面向对象的程序，其依赖程序相对于传统的过程式方法设计的通常结构而言就是被倒置了。依赖倒置是”松耦合“ 设计的很好体现，高层模块不直接依赖低层的实现，而是依赖于低层模块的抽象。高层模块不应该依赖于低层模块，二者应该依赖于抽象。而抽象不应该依赖于细节，细应该依赖于抽象。
这段话很拗口，简单点通俗来讲，比如一个A 依赖于 B，如果A 需要实现另外的功能，需要依赖于B的具体改动才能完成，这就增加了两者之家的耦合性。这时如果A与B之间增加一个C来承接A的抽象实现，A与B之间就不具备很强的依赖关系了。这样A就把对B的依赖控制在了手里，A不在依赖于B，而B却需要依赖A的功能抽象类C。这也是注明的Hollywood原则，”Don’t call us，we call you“，底层模块实现了在高层模块中的声明并被高层模块调用的接口，导致了接口的所有权。
依赖于抽象，程序中所有的依赖关系都应该终止与抽象类或者接口
一个稍微简单但仍然非常有效的对于DIP的解释：”依赖于抽象“。程序中所有的依赖关系都应该终止于抽象类或者接口。
- 任何变量都不应该持有一个指向具体类的指针或者引用
- 任何类都不应该从具体类派生
- 任何方法都不应该复写他的任何基类中的已经实现了的方法
当然每个程序中都会有违反该启发规则的情况。
依赖倒置放置在哪？
我们只聊依赖倒置，软件的设计，但是难免又会涉及到了软件的分层结构。传统的大部分公司我们都在使用分层架构，简单的三层架构会使得面向对象的特点一点点在工作中蒸发。controller、service、dao基本决定了大部分应用场景的模型，service层中通常会用来定义抽象与抽象接口的实现，虽然上层会使用抽象调用业务具体实现，但是按照上文中依赖倒置原则的划分，分包逻辑却似乎不正确。
区别于传统分层模型的另一种软件设计思想是领域驱动设计（DDD，这篇不做过分涉及），在DDD中严格约束下层对象不能调用上层，其中传统的DDD四层模型会有用户接口层、应用层、领域层、基础设施层，我们拿领域层的一处实现来说，领域层中会有实体、值对象、事件、领域服务、资源库等，在这里资源库负责DAO层处理，这里提出好的意思是，我们可以把抽象层单独分包为独立的一层facade层负责处理业务的抽象，具体的实现我们可以单独抽离为persistence负责业务的实现处理，这样虽然看起来和三层分层结构没有区别，但是从意义上我们更贴近了依赖倒置，后续也会使得扩展更简单。
接口可以被许多不同的客户使用，并被许多不同的服务者实现。这样我们接口就放置在了一个单独的组中去控制依赖倒置的关系。