何时传出/传出耦合好坏

我这周要参加软件模式考试，我们要学习的主题之一是传出和传出耦合。

我了解，如果封装依赖于许多其他类型，则封装的Ce（有效耦合）较高。

例如：

class Car{
    Engine engine;
    Wheel wheel;
    Body body;
}

该类具有较高的传出联轴器，因为它取决于引擎，车轮和车身类型。

如果“ Wheel”类型依赖于其他几个包装（汽车，飞机，自行车），则Ca（费伦特耦合）会较高。

我们考试中可能出现的问题之一是，何时传出/传出耦合好坏？这在我看来很奇怪，因为从逻辑上讲，程序需要具有高传入/传入耦合的包/类。

有没有人举例说明何时/何处高传出或传入耦合好/不好？

谢谢 ！

传入耦合可以最容易地根据由于更改的必要性或可能性而导致/减轻的疼痛程度进行评估。例如，以您的车轮类为例，假设许多其他模块使用它来制造各种车辆。如果车轮类别非常稳定，则这种传入耦合是有益的，因为车辆需要车轮并且它们使用的是可靠的车轮。另一方面，如果轮类在维护方面易变，则在将重复更改引入大量代码的过程中，这种传入耦合将是一个痛点。

传出耦合在概念上相似，但是您将要研究一个稍有不同的价值主张。如果您的汽车类直接依赖于很多单独的部分（而不是只说“引擎”和“底盘”，并且它们由其他子部分组成），则该类可能做得很多，因此可能是维护瓶颈。由于该类的复杂性，对其进行更改很可能是困难且冒险的。另一方面，如果传出耦合很高，但实际上衔接清晰，那么您就不必担心对象和关系的层次结构。

当涉及到架构/设计时，您真正需要考虑的是无尽的权衡，这些指标没有什么不同。如果您想举例说明某件事情是好是坏，请玩“假设”游戏。想象一个例子，说“如果我想做X怎么办？那会吸多少呢？” 对于答案是“很多”的X，您有一个劣势；对于答案是“实际上很简单”的X，您有一个优势。

一般而言，松散耦合：

积极的：保护系统的一部分免受其所依赖的变化（afferent耦合）

负面的：关系可能更难以理解

例如，如果我正在开发依赖于HTTTP的系统，那么我将决定是否需要紧密或松散地耦合到HTTP。如果我认为系统可能会切换到其他协议，则可以选择宽松地耦合到该协议，而如果我接受HTTP是我的协议，则可以紧密耦合到该协议以简化理解。

考虑到WS *中的某些复杂性在于它与HTTP作为协议的分离。

传入

如果某件东西使用了一堆不同的东西（大量传入耦合），那么如果这些东西中的任何一件发生变化，它很可能会崩溃。

_{不稳定= 1}

传出

如果一堆不同的东西使用了某些东西（大量的传出耦合），那么如果它发生变化，很可能会破坏很多东西。

_{不稳定= 0}

稳定性

马丁对“稳定性”的定义是“难以改变”和“几乎没有改变的理由”之间的奇特混合。然而，他的不稳定指标仅描述了“变化的难度”。“改变的原因”将与无法轻易计算的因素有更多关系，例如只是在适当的抽象级别上适当地设计界面，以及更清楚地预先了解用户端需求。

因此，高传入耦合与低传入耦合产生稳定性（如在某些难以更改的事物中，因为它会破坏一堆东西），相反的生成不稳定（如在易于更改的事物中，因为它不会破坏一堆东西） 。

大量的传入耦合可能表明您的设计缺乏重点-它使用了一堆不同的东西，因此可能缺乏明确，单一的职责。

起初，大量传出的联轴器可能被解释为是一件好事，因为这表明您的设计正在被广泛使用。但是，如果您经常尝试以破坏一切的方式来更改设计，那将是不好的。因此，随着大量传出接头的出现，这种包装就需要“很少或没有理由更换”。设计在没有更改理由的理想意义上应该是稳定的，因为同样很难更改。

稳定抽象原理

诸如依赖倒置（自然要求依赖注入）和SAP（稳定抽象原理）之类的概念都表明依赖流向抽象。有一个简单的原因可以说明为什么在“很少有改变的理由”的情况下考虑“稳定性”。抽象的界面没有提及具体细节，它只关注“做什么”而不是“事情是什么”，因此更改的原因更少。与插入显卡的GPU（具体细节）相比，我们主板上的加速图形端口（抽象接口）具有更少的理由进行设计更改。

可重用性与重用性

如果我可以提出一个与Martin有点冲突的个人度量标准，那么我想推动这一观点，即最可重用的库应寻求以最小的方式重用其他代码。这就将不稳定推向了0。这是出于实际的原因，即更改的原因最少，而且还促进了最容易部署的库。依赖于十二个不同库的，用途广泛的通用库具有许多更改原因，并且分发的捆绑包很复杂，可能难以部署。此处的区别在于，在我的案例中，“更改原因”甚至扩展到实现，因为它来自旨在发布稳定版本库的面向库的视图。Martin可能会将实施视为一个非常独立的部分，

从分发的角度来看，实现和界面会模糊在一起，从而使用户对稳定或不稳定的库产生依赖性。从接口的角度来看，仅使用接口，并且相关的实现细节是完全分开的。