分享程序员开发的那些事...
更新时间：2022-08-16 08:24:30
Dependence Inversion Principle，DIP
High level modules should not depend upon low level modules.Both should depend upon abstractions.高层模块不应该依赖低层模块，二者都应该依赖其抽象
Abstractions should not depend upon details.Details should depend upon abstractions.抽象不应该依赖细节；细节应该依赖抽象
针对接口编程，不要针对实现编程。
每个逻辑的实现都是由原子逻辑组成的，不可分割的原子逻辑就是低层模块，原子逻辑的再组装就是高层模块
在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的
细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是可以直接被实例化，也就是可以加上一个关键字new产生一个对象。
依赖倒置原则在Java语言中的表现就是：
● 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；
● 接口或抽象类不依赖于实现类；
● 实现类依赖接口或抽象类。
优点：可以减少类间的耦合性、提高系统稳定性，提高代码可读性和可维护性，可降低修改程序所造成的风险。
能不能把依赖弄对，要动点脑。依赖关系没处理好，就会导致一个小改动影响一大片。
把依赖方向搞反，就是最典型错误。
最重要的是要理解“倒置”，而要理解什么是“倒置”，就要先理解所谓的“正常依赖”是什么样的。
结构化编程思路是自上而下功能分解，这思路很自然地就会延续到很多人的编程习惯。按照分解结果，进行组合。所以，很自然地写出下面这种代码
这种结构天然的问题：高层模块依赖于低层模块：
CriticalFeature是高层类
Step1和Step2就是低层模块，而且Step1和Step2通常都是具体类
很多人好奇了：step1和step2如果是接口，还有问题吗？像这种流程式的代码还挺常见的?
有问题，你无法确定真的是Step1和Step2，还会不会有Step3，所以这个设计依旧是不好的。如果你的设计是多个Step，这也许是个更好的设计。
在实际项目中，代码经常会直接耦合在具体的实现上。比如，我们用Kafka做消息传递，就在代码里直接创建了一个KafkaProducer去发送消息。我们就可能会写出这样的代码：
我用Kafka发消息，创建个KafkaProducer，有什么问题吗？
我们需要站在长期角度去看，什么东西是变的、什么东西是不变的。Kafka虽然很好，但它并不是系统最核心部分，未来是可能被换掉的。
你可能想，这可是我的关键组件，怎么可能会换掉它？
软件设计需要关注长期、放眼长期，所有那些不在自己掌控之内的东西，都有可能被替换。替换一个中间件是经常发生的。所以，依赖于一个可能会变的东西，从设计的角度看，并不是一个好的做法。
那该怎么做呢？这就轮到倒置了。
倒置，就是把这种习惯性的做法倒过来，让高层模块不再依赖低层模块。
功能该如何完成？
计算机科学中的所有问题都可以通过引入一个间接层得到解决。 All problems in computer science can be
solved by another level of indirection —— David Wheeler
引入一个间接层，即DIP里的抽象，软件设计中也叫模型。这段代码缺少了一个模型，而这个模型就是这个低层模块在这个过程中所承担角色。
既然这个模块扮演的就是消息发送者的角色，那我们就可以引入一个消息发送者（MessageSender）的模型：
有了消息发送者这个模型，又该如何把Kafka和这个模型结合呢？
实现一个Kafka的消息发送者：
这样高层模块就不像之前直接依赖低层模块，而是将依赖关系“倒置”，让低层模块去依赖由高层定义好的接口。
好处就是解耦高层模块和低层实现。
若日后替换Kafka，只需重写一个MessageSender，其他部分无需修改。这就能让高层模块保持稳定，不会随低层代码改变。
这就是建立模型（抽象）的意义。
所有软件设计原则都在强调尽可能分离变的部分和不变的部分，让不变的部分保持稳定。
模型都是相对稳定的，而实现细节是易变的。所以，构建稳定的模型层是关键。
抽象不应依赖于细节，细节应依赖于抽象。
简单理解：依赖于抽象，可推出具体编码指导：
当然了，如上指导并非绝对。若一个类特稳定，也可直接用，比如String 类，但这种情况很少！
因为大多数人写的代码稳定度都没人家 String 类设计的高。
首先定义一个学习者类
简单的测试类
假如现在又想学习Python，则面向实现编程就是直接在类添加方法
此类需经常改变，扩展性太差，Test 高层模块, Learner 类为低层模块，耦合度过高！
让我们引入抽象：
现在就能将原学习者类的方法都消除