在上一篇文章中，我们讨论了ISP原则。当我们知道在设计界面时，我们应该设计一个小界面，并且我们不应该让用户依靠无法使用的方法。
依靠这个词，程序员理解，这意味着我使用此代码，我依靠谁。这很容易依赖，但是您是否可以做正确的事，您需要移动您的思想。它将导致很小的变化影响大面积，而依赖方向将是最典型的错误。
那么，与之抗争的依赖方向是什么？让我们讨论依赖的设计原理：反演的原理。
依赖性反转原理（DIP）如下所示：
高级别的模块不应取决于低级别的模块，并且两者都应取决于抽象。
摘要不应取决于细节，细节应取决于抽象。
要学习这一原则，最重要的是要理解“倒置”，并了解“倒置”是什么，您必须首先了解所谓的“正常依赖关系”的样子。
我们自然编写以下代码：
但是，存在这种不规则结构的问题：高级别的模块取决于低级别的模块。在上述代码中，Criedic Feature类是高级别类，STEP1和Step2是低级别的模块，而STEP1和STEP1和Step2通常是特定的类。尽管这是一种自然的方式，但这篇文章确实是一个问题。
在实际项目中，代码通常直接伴侣与特定的实现。
也许您会问，我只是使用Kafka发送消息来创建Kafkaproducer。有什么问题吗？实际上，我们需要长时间查看它。发生了什么变化和恒定。尽管卡夫卡非常好，但它不是系统的核心部分。我们将来可能会替换它。
您可能会认为，这是我意识到的关键组成部分，我该如何更改它？软件设计需要长期注意，长时间查看它，并且所有不在您自己控制中的事物都可以更换实际上，替换中间件经常发生。因此，这不是依赖可能改变的事物的好方法。从设计的角度来看，我们应该做什么？这是转机。
这样被称为倒置的是扭转这种习惯方法，以便高级模块不再依赖低级模块。因此，如果我们的功能如何完成？计算机行业中的一句话告诉我们：答案：
计算机科学中的所有问题都可以通过引入间接层来解决。
是的，引入间接层。此间接层是指dip中的抽象。换句话说，该代码缺乏模型，并且该模型是此低级别模块在此过程中的作用。
由于该模块扮演消息发件人的角色，因此我们可以介绍消息发送者的模型（MessageEnder）：
使用此模型，我们如何将KAFKA与此模型相结合？然后意识到Kafka的消息发送者：
消费者可以消费这样的信息：
这样，高级别的模块不直接依赖低级别的模块，而是依靠“反向”依赖关系来允许低级别的模块依赖于高级别的接口。这样的优点是分解高级别模块和低级别。
如果将来需要用RabbitMQ替换Kafka，只需写一个消息架，其他部分就不需要更改。这样，我们可以保持高级别的模块相对稳定，并且不会随着低点的变化而改变 -级别代码。
消费者可以消费这样的信息：
摘要不应取决于细节，细节应取决于抽象。
实际上，这可以更简单地理解：从这一点开始，我们可以得出一些更具体的编码规则：
例如，列表语句的实际上，第一个规则在这里遵循规则：
在实际项目中，这些编码规则有时不是绝对的。如果类特别稳定，我们也可以直接使用它，例如字符串类。因此，上面的编码规则可以成为涵盖大多数情况的规则。如果有例外，我们需要特别注意。
作者：第一次思考和初恋