有了消息发送者这个模型，又该如何把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如果要开宝马车，也很容易，只需修改业务场景类即可。
在新增加低层模块时，只修改了业务场景类，也就是高层模块，对其他低层模块如Driver类不需要做任何修改，业务就可以运行，把“变更”引起的风险扩散降到最低。
Java只要定义变量就必然要有类型，一个变量可以有两种类型：
- 表面类型
在定义的时候赋予的类型
- 实际类型
对象的类型，如java的表面类型是IDriver，实际类型是Driver。
思考依赖倒置对并行开发的影响。两个类之间有依赖关系，只要制定出两者之间的接口（或抽象类）即可独立开发，而且项目之间的单元测试也可以独立地运行，而TDD（Test-Driven Development，测试驱动开发）开发模式就是依赖倒置原则的最高级应用。
回顾司机驾驶汽车的例子：
-
甲程序员负责IDriver开发
-
乙程序员负责ICar的开发
两个开发人员只要制定好了接口就可以独立地开发了，甲开发进度比较快，完成了IDriver以及相关的实现类Driver的开发工作，而乙程序员滞后开发，那甲是否可以进行单元测试呢？
根据抽象虚拟一个对象进行测试：
只需要一个ICar接口，即可对Driver类进行单元测试。
这点来看，两个相互依赖的对象可分别进行开发，各自独立进行单元测试，保证了并行开发的效率和质量，TDD开发的精髓不就在这？
TDD，先写好单元测试类，然后再写实现类，这对提高代码的质量有非常大的帮助，特别适合研发类项目或在项目成员整体水平较低情况下采用。
抽象是对实现的约束，对依赖者而言，也是一种契约，不仅仅约束自己，还同时约束自己与外部的关系，其为保证所有细节不脱离契约范畴，确保约束双方按既定契约（抽象）共同发展，只要抽象这根基线在，细节就脱离不了这个圈圈。
===================================================================
依赖可以传递，A对象依赖B对象，B又依赖C，C又依赖D……
只要做到抽象依赖，即使是多层的依赖传递也无所畏惧！
对象的依赖关系有如下传递方式：
在类中通过构造器声明依赖对象，构造函数注入
在抽象中设置Setter方法声明依赖关系,Setter依赖注入
在接口的方法中声明依赖对象
=====================================================================
依赖倒置原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合。
DIP指导下，具体类能少用就少用。
具体类我们还是要用的，毕竟代码要运行起来不能只依赖于接口。那具体类应该在哪用？
这些设计原则，核心关注点都是一个个业务模型。此外，还有一些代码做的工作是负责组装这些模型，这些负责组装的代码就需要用到一个个具体类。
做这些组装工作的就是DI容器。因为这些组装几乎是标准化且繁琐。如果你常用的语言中，没有提供DI容器，最好还是把负责组装的代码和业务模型放到不同代码。
DI容器另外一个说法叫IoC容器，Inversion of Control，你会看到IoC和DIP中的I都是inversion，二者意图是一致的。
依赖之所以可注入，是因为我们的设计遵循 DIP。而只知道DI容器不了解DIP，时常会出现让你觉得很为难的模型组装，根因在于设计没做好。
DIP还称为好莱坞规则：“Don’t call us, we’ll call you”，“别调用我，我会调你的”。这是框架才会有的说法，有了一个稳定抽象，各种具体实现都应由框架去调用。
为什么说一开始TransactionRequest是把依赖方向搞反了？因为最初的TransactionRequest是一个具体类，而TransactionHandler是业务类。
我们后来改进的版本里引入一个模型，把TransactionRequest变成了接口，ActualTransactionRequest 实现这个接口，TransactionHandler只依赖于接口，而原来的具体类从这个接口继承而来，相对来说，比原来的版本好一些。
对于任何一个项目而言，了解不同模块的依赖关系是一件很重要的事。你可以去找一些工具去生成项目的依赖关系图，然后，你就可以用DIP作为一个评判标准，去衡量一下你的项目在依赖关系上表现得到底怎么样了。很有可能，你就找到了项目改造的一些着力点。
理解了 DIP，再来看一些关于依赖的讨论，我们也可以看到不同的角度。
比如，循环依赖，循环依赖就是设计没做好的结果，把依赖关系弄错，才可能循环依赖，先把设计做对，把该有的接口提出来，就不会循环了。
我们怎么在项目中使用这个规则呢？只要遵循以下的几个规则就可以：
- 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备
这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置
3511
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
