背景

这几天组内的人一起学习DDD,里面再次提到了依赖倒置原则,在这学习过程中,大家又讨论了一下依赖倒置原则。

说明

采用依赖倒置原则可以减少类间的耦合性,提高系统的稳定性,减少并行开发引起的风险,提高代码的可读性和可维护性。

那么依赖倒置原则是什么呢?

高层次的模块不应该依赖于低层次的模块,他们都应该依赖于抽象。

抽象不应该依赖于具体,具体应该依赖于抽象。

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Abstractions should not depend on details. Details should depend on abstractions.

依赖倒置原则是Robert C. Martin在1996年为“C++Reporter”所写的专栏Engineering Notebook的第三篇,后来加入到他在2002年出版的经典著作“Agile Software Development, Principles,Parrerns,and Practices”一书中。

例子

下面是一个违反依赖倒置原则的示例。我们有高层类Manager,还有底层类Worker。现在我们需要在应用程序中增加一个新模块,以模拟由雇用新专业工人决定的公司结构变化,我们为此创建了一个新的类SuperWorker

让我们假设Manager类相当复杂,包含非常复杂的逻辑。现在我们必须改变它,以引入新的SuperWorker。让我们看看缺点:

  • 我们必须更改类Manager(记住这是一个复杂的类,这将涉及时间和精力进行更改)。
  • Manager类中的某些功能可能会受到影响。
  • 单元测试应重做。

所有这些问题都可能需要很多时间来解决,并且它们可能会在旧功能中诱发新的错误。如果应用程序是按照依赖倒置原则来设计的,情况就不一样了。这意味着我们设计Manager类时,IWorker 接口和实现 IWorker 接口的Worker类即可。当我们需要添加SuperWorker时,我们要做的就是为此实现IWorker接口。现有类没有其他更改。

// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
} class Manager {
Worker worker; public void setWorker(Worker w) {
worker = w;
} public void manage() {
worker.work();
}
} class SuperWorker {
public void work() {
//.... working much more
}
}

以下是支持依赖性反转原则的代码。在这个新设计中,通过IWorker 界面添加了一个新的抽象层。现在,上述代码中的问题已经解决(考虑到高层逻辑没有变化):

  • 在添加SuperWorker时,Manager类不需要更改。
  • 由于我们不会改变它,因此最大限度地降低影响Manager器类中当前旧功能的风险。
  • 无需重做Manager类的单元测试。
// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
} class Worker implements IWorker{
public void work() {
// ....working
}
} class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
} class Manager {
IWorker worker; public void setWorker(IWorker w) {
worker = w;
} public void manage() {
worker.work();
}
}

当然,使用此原则意味着加大努力,将导致更多的类和接口来维护,换句话说,在更复杂的代码,但更灵活。不应盲目地将这一原则应用于每个类或每个模块。如果我们的类功能将来更有可能保持不变,则无需应用此原则。

“倒置”的解释

《设计模式之禅》中对“倒置”的解释:

讲了这么多,估计大家对“倒置”这个词还是有点不理解,那到底什么是“倒置”呢?我们先说“正置”是什么意思,依赖正置就是类间的依赖是实实在在的实现类间的依赖,也就是面向实现编程,这也是正常人的思维方式,我要开奔驰车就依赖奔驰车,我要使用笔记本电脑就直接依赖笔记本电脑,而编写程序需要的是对现实世界的事物进行抽象,抽象的结果就是有了抽象类和接口,然后我们根据系统设计的需要产生了抽象间的依赖,代替了人们传统思维中的事物间的依赖,“倒置”就是从这里产生。

可以这么解释:高层A依赖于低层B修改为高层A依赖于抽象层C,低层B依赖于抽象层C,而抽象层C是低层B的高层,所以说低层依赖于高层了,即倒置。但是A依赖于C,这个不能说是低层依赖于高层吧,A和C谁高谁低是这么判定的?因为抽象层C是属于A层的,即由A层来规定抽象层C的接口规范,而B是对C的实现,因此通过引入C层实现了“依赖倒置”。

总结

一句话:依赖倒置原则的核心就是面向抽象(抽象类或者接口)编程。

设计类结构的方法是从高层模块到底层模块:

高层类 --> 抽象层 --> 底层类

参考资料

依赖倒置原则(Dependence Inversion Principle)的更多相关文章

  1. 设计模式六大原则(三):依赖倒置原则(Dependence Inversion Principle)

    依赖倒置原则(DIP)定义: 高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 问题由来: 类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码 ...

  2. 依赖倒置原则(Dependence Inversion Principle,DIP)

    依赖倒转原则就是 A.要依赖于抽象,不要依赖于实现.(Abstractions should not depend upon details. Details should depend upon a ...

  3. 依赖倒置(Dependence Inversion Principle)DIP

    关于抽象类和接口的区别,可以参考之前的文章~http://www.cnblogs.com/leestar54/p/4593173.html using System; using System.Col ...

  4. 依赖倒置原则(Dependency Inversion Principle)

    很多软件工程师都多少在处理 "Bad Design"时有一些痛苦的经历.如果发现这些 "Bad Design" 的始作俑者就是我们自己时,那感觉就更糟糕了.那么 ...

  5. DesignPattern系列__03依赖倒置原则

    依赖倒置原则(Dependence Inversion Priiciple,DIP) 介绍 High level modules should not depend upon low level mo ...

  6. 面象对象设计原则之五:依赖倒置原则(The Dependency Inversion Principle,DIP)

    如果说开闭原则是面向对象设计的目标的话,那么依赖倒转原则就是面向对象设计的主要实现机制之一,它是系统抽象化的具体实现.依赖倒转原则是Robert C. Martin在1996年为“C++Reporte ...

  7. 【面向对象设计原则】之依赖倒置原则(DIP)

    依赖倒转原则(Dependency Inversion  Principle, DIP):抽象不应该依赖于细节,细节应当依赖于抽象.换言之,要针对抽象(接口)编程,而不是针对实现细节编程. 开闭原则( ...

  8. 3.依赖倒置原则(Dependence Inversion Principle)

    1.定义 高层模块不应该依赖于低层模块,二者都应该依赖于抽象:抽象不应该依赖细节:细节应该依赖抽象. 2.定义解读 依赖倒置原则在程序编码中经常运用,其核心思想就是面向接口编程,高层模块不应该依赖低层 ...

  9. 【设计模式六大原则3】依赖倒置原则(Dependence Inversion Principle)

      定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类 ...

随机推荐

  1. 使用 dynamic 类型让 ASP.NET Core 实现 HATEOAS 结构的 RESTful API

    上一篇写的是使用静态基类方法的实现步骤:  http://www.cnblogs.com/cgzl/p/8726805.html 使用dynamic (ExpandoObject)的好处就是可以动态组 ...

  2. Git 在解决冲突的时候文件覆盖

    更新代码导致被还原或覆盖的场景:1.触发冲突的必要条件是修改同一个文件且修改的位置非常近,否则Git会自动合并其内容避免更新代码导致被还原或覆盖的解决方案1.少修改的地方(生产环境.公网测试环境):推 ...

  3. [源码解析] 并行分布式框架 Celery 之 worker 启动 (2)

    [源码解析] 并行分布式框架 Celery 之 worker 启动 (2) 目录 [源码解析] 并行分布式框架 Celery 之 worker 启动 (2) 0x00 摘要 0x01 前文回顾 0x2 ...

  4. Spring Boot 轻量替代框架 Solon 1.3.18 发布

    Solon 是一个微型的Java开发框架.项目从2018年启动以来,参考过大量前人作品:历时两年,4000多次的commit:内核保持0.1m的身材,超高的跑分,良好的使用体验.支持:RPC.REST ...

  5. Async Cow Python 七牛异步SDK

    # Async Cow Python 七牛异步SDK > gitee链接 >github链接本SDK基于官方SDK改造而成,但又对其进行了进一步封装,简化了相关操作例如:- 1.不需要使用 ...

  6. Codeforces-121C(逆康托展开)

    题目大意: 给你两个数n,k求n的全排列的第k小,有多少满足如下条件的数: 首先定义一个幸运数字:只由4和7构成 对于排列p[i]满足i和p[i]都是幸运数字 思路: 对于n,k<=1e9 一眼 ...

  7. 《环形队列》游戏高《TPS》模式下减少cpu线程切换

    序言 什么高TPS?QPS,其实很多人都知道,还有人说大数据,大流量这些关键词夜以继日的出现在我们眼前: 针对高TPS,QPS这些词汇还有一个次可能比较陌生那就是CCU,tps,qps接受满天飞,CC ...

  8. Hadoop学习笔记—Yarn

    目录 一些基本知识 ResourceManager 的恢复 Resource Manager的HA YARN Node Labels YARN Node Attributes Web Applicat ...

  9. OO_Unit 3 JML规格化设计总结

    OO_Unit 3 JML规格化设计总结 JML语言概述(Level 0) 概念定义   JML(Java Modeling Language)是用于对Java程序进行规格化设计的一种表示语言.JML ...

  10. jdbcTemplate事务管理

    1.基于TransactionTemplate的编程式事务管理 Spring之路(39)–基于TransactionTemplate的编程式事务管理 本篇通过TransactionTemplate类, ...