针对接口编程，不要针对实现编程。
每个逻辑的实现都是由原子逻辑组成的，不可分割的原子逻辑就是低层模块，原子逻辑的再组装就是高层模块
在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，其他部分无需修改。这就能让高层模块保持稳定，不会随低层代码改变。
这就是建立模型（抽象）的意义。
所有软件设计原则都在强调尽可能分离变的部分和不变的部分，让不变的部分保持稳定。
模型都是相对稳定的，而实现细节是易变的。所以，构建稳定的模型层是关键。
====================================================================
抽象不应依赖于细节，细节应依赖于抽象。
简单理解：依赖于抽象，可推出具体编码指导：
- 任何变量都不应该指向一个具体类
如最常用的List声明
-
任何类都不应继承自具体类
-
任何方法都不应该改写父类中已经实现的方法
当然了，如上指导并非绝对。若一个类特稳定，也可直接用，比如String 类，但这种情况很少！
因为大多数人写的代码稳定度都没人家 String 类设计的高。
首先定义一个学习者类
简单的测试类
假如现在又想学习Python，则面向实现编程就是直接在类添加方法
此类需经常改变，扩展性太差，Test 高层模块, Learner 类为低层模块，耦合度过高！
让我们引入抽象：
现在就能将原学习者类的方法都消除
===================================================================
采用依赖倒置原则可减少类间耦合，提高系统稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。
证明一个定理是否正确，有两种常用方法：
- 顺推证法
根据论题，经过论证，推出和定理相同结论
- 反证法
先假设提出的命题是伪命题，然后推导出一个与已知条件互斥结论
反证法来证明依赖倒置原则的优秀！
依赖倒置原则可减少类间的耦合性，提高系统稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。
不使用依赖倒置原则也可减少类间的耦合性，提高系统稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。
通过一个例子来说明反论题不成立！
- 司机驾驶奔驰车类图
奔驰车可提供一个方法run，代表车辆运行：
司机通过调用奔驰车的run方法开动奔驰车
有车，有司机，在Client场景类产生相应的对象
现在来了新需求：张三司机不仅要开奔驰车，还要开宝马车，又该怎么实现呢？
走一步是一步，先把宝马车产生出来
宝马车产生了，但却没有办法让张三开起来，为什么？
张三没有开动宝马车的方法呀！一个拿有C驾照的司机竟然只能开奔驰车而不能开宝马车，这也太不合理了！在现实世界都不允许存在这种情况，何况程序还是对现实世界的抽象。
我们的设计出现了问题：司机类和奔驰车类紧耦合，导致系统可维护性大大降低，可读性降低。
两个相似的类需要阅读两个文件，你乐意吗？还有稳定性，什么是稳定性？固化的、健壮的才是稳定的，这里只是增加了一个车类就需要修改司机类，这不是稳定性，这是易变性。
被依赖者的变更竟然让依赖者来承担修改成本，这样的依赖关系谁肯承担？
证明至此，反论题已经部分不成立了。
继续证明，“减少并行开发引起的风险”
什么是并行开发的风险？
并行开发最大的风险就是风险扩散，本来只是一段程序的异常，逐步波及一个功能甚至模块到整个项目。一个团队，一二十个开发人员，各人负责不同功能模块，甲负责汽车类的建造，乙负责司机类的建造，在甲没有完成的情况下，乙是不能完全地编写代码的，缺少汽车类，编译器根本就不会让你通过！在缺少Benz类的情况下，Driver类能编译吗？更不要说是单元测试了！在这种不使用依赖倒置原则的环境中，所有开发工作都是“单线程”，甲做完，乙再做，然后是丙继续……这在20世纪90年代“个人英雄主义”编程模式中还是比较适用的，一个人完成所有的代码工作。但在现在的大中型项目中已经是完全不能胜任了，一个项目是一个团队协作的结果，一个“英雄”再牛也不可能了解所有的业务和所有的技术，要协作就要并行开发，要并行开发就要解决模块之间的项目依赖关系，那然后呢？
依赖倒置原则隆重出场！
根据以上证明，若不使用依赖倒置原则就会加重类间的耦合性，降低系统的稳定性，增加并行开发引起的风险，降低代码的可读性和可维护性。
引入DIP后的UML：
建立两个接口：IDriver和ICar，分别定义了司机和汽车的各个职能，司机就是驾驶汽车，必须实现drive()方法
接口只是一个抽象化的概念，是对一类事物的最抽象描述，具体的实现代码由相应的实现类来完成
IDriver通过传入ICar接口实现了抽象之间的依赖关系，Driver实现类也传入了ICar接口，至于到底是哪个型号的Car，需要声明在高层模块。
ICar及其两个实现类的实现过程：
业务场景应贯彻“抽象不应依赖细节”，即抽象（ICar接口）不依赖BMW和Benz两个实现类（细节），因此在高层次的模块中应用都是抽象：
Client属于高层业务逻辑，它对低层模块的依赖都建立在抽象上，java的表面类型是IDriver，Benz的表面类型是ICar。
在这个高层模块中也调用到了低层模块，比如new Driver()和new Benz()等，如何解释？
java的表面类型是IDriver，是一个接口，是抽象的、非实体化的，在其后的所有操作中，java都是以IDriver类型进行操作，屏蔽了细节对抽象的影响。当然，java如果要开宝马车，也很容易，只需修改业务场景类即可。
最后
这份《“java高分面试指南”-25分类227页1000+题50w+字解析》同样可分享给有需要的朋友，感兴趣的伙伴们可挑战一下自我，在不看答案解析的情况，测试测试自己的解题水平，这样也能达到事半功倍的效果！（好东西要大家一起看才香）
加入社区：https://bbs.csdn.net/forums/4304bb5a486d4c3ab8389e65ecb71ac0
实体化的，在其后的所有操作中，java都是以IDriver类型进行操作，屏蔽了细节对抽象的影响。当然，java如果要开宝马车，也很容易，只需修改业务场景类即可。
最后
这份《“java高分面试指南”-25分类227页1000+题50w+字解析》同样可分享给有需要的朋友，感兴趣的伙伴们可挑战一下自我，在不看答案解析的情况，测试测试自己的解题水平，这样也能达到事半功倍的效果！（好东西要大家一起看才香）
[外链图片转存中…(img-CY4dw1GN-1725669477661)]
[外链图片转存中…(img-AmxZ6aVQ-1725669477662)]
加入社区：https://bbs.csdn.net/forums/4304bb5a486d4c3ab8389e65ecb71ac0
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
