设计模式（8）——SOLID原则之依赖倒置原则
概念高条理的类不应该依赖于低条理的类。两者都应该依赖于抽象接口。抽象接口不应依赖于具体实现。具体实现应该依赖于抽象接口。
[*]底条理类：实现基础利用的类（如磁盘利用、传输网络数据与利用数据库）。
[*]高条理类：包含负责的业务逻辑以指导底条理类执行特定利用。
利用
当开发新体系时，偶然人们风俗先设计底条理类，然后再开发高层此类。一部分人直观以为如果低条理的类没有实现或不确定，就无法确定高条理类能实现哪些东西。如果采用了这种设计思绪，那高条理类更有可能会依赖低条理类。
依赖倒置原则发起采用以下方式设计：
[*]利用业务术语来对高条理类依赖的低条理利用接口进行形貌。比方打开报表文件，业务应该调用的是openReport(file)，而不是openFile()、readBytes()和CloseFile()等低条理类中的方法。
[*]基于上述业务术语抽象的接口创建高条理类，而不是基于低条理类
[*]低条理实现接口，它们将依赖业务逻辑层，从而完成了依赖倒置
示例
在本例中，高条理的预算陈诉类（BudgetReport）利用低条理的数据库类（MySQLDatabase）来读取和保存其数据。这意味着低条理类中的任何改变（比方当数据库服务器发布新版本时）都可能会影响到高条理的类，但高条理的类不应关注数据存储的细节。
https://i-blog.csdnimg.cn/direct/f46c7f6cca7c421fbced88f82f0f153a.png
要解决这个题目，你可以创建一个形貌读写利用的高层接口，并让陈诉类利用该接口取代低条理的类。然后你可以修改或扩展低条理的原始类来实现业务逻辑声明的读写接口。
https://i-blog.csdnimg.cn/direct/66f66ff687a04651a9b284970d1896ca.png
其结果是原始的依赖关系被倒置：现在低条理的类依赖于高条理的抽象。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]