耦合 - 除了更改方法签名或返回类型之外，更改一个模块如何影响另一个模块？

Question

在高耦合环境中，更改一个模块会影响另一个模块。 好的，但我看不出这怎么可能（除了更改方法签名或返回类型）？

好吧，如果我更改一个 class ，那么它只能在以下情况下破坏其他 class 中的代码：

1. 如果我突然更改方法的返回类型 - 那么我将不得不将 go 更改为另一个 class 并修复类型的不匹配。
2. 如果我更改方法签名 - 那么我必须将 go 更改为所有依赖类，并在调用更改的方法的任何地方更改方法 arguments 。

出于同样的原因，依赖抽象（接口）是很好的，这样我们就可以保证定义的方法会在那里。

除此之外，更改 class 还能如何影响另一个依赖 class？

Answer 1

即使这被标记为“Java”，我也会给出一个更广泛的答案。

耦合用模块 A 在使用模块 B 时做出的假设来表示。模块 A 做出的假设越多，它与模块 B 的耦合就越多。

一个模块的 API 基本上是它的消费者可以做出的一组假设。 返回类型或方法签名只是编译器可以验证的假设。

例如， SimCity 与 Windows 3.x memory allocator 结合使用。 memory 分配器有一个合同说你可以假设 X、Y 和 Z，就是这样。 不能假设任何其他行为。 但是 SimCity 假设了它，因此，他们无法更改 Windows 95 中的 memory 分配器（好吧，不是在 SimCity 执行时）。

显然这不是有意的耦合——任何关于模块超出其接口的假设都应该是无意的，但这仍然是一个假设。

其他示例包括：

• 密码散列 API 告诉其消费者 hash 算法是什么。 然后，消费者可能会将散列密码的长度硬编码到数据库模式中，这意味着只有在数据库迁移之后才能将其更改为具有更长散列的更安全算法。
• 使用 protobuf 的每个人不仅与它的 API 耦合，而且与它的有线格式耦合。 如果 Google 想要更改有线格式，它将破坏生产者或消费者尚未升级的所有部署。
• 如果您使用例如GCC 的 GNU 编译器扩展，那么您将与 GCC 结合使用。 如果您想（或必须）使用另一个编译器，您最好希望它们也恰好实现相同的扩展。
• 每个程序都与它的编程语言耦合。 For example, if Oracle wanted to change Java so that function overloading is not possible eg because of some fatal design bug that only manifests once in 100 years, all Java programs would stop compiling.
• 如果你编写一个 POSIX 程序，你依赖于 POSIX 的实现。 如果您的 POSIX 程序使用POSIX basename(3) ，但您的实现破坏了它的语义，那么您的程序就不能在这个实现上工作（GNU 引入了一个兼容性宏来避免这种情况）。

Answer 2

假设您是 class A 的作者，它按 object 的任何属性按升序对对象进行简单排序。

比如说，class B 和 C，使用该功能以某种方式处理列表。 Class B 是严格的，它只想按升序对对象进行排序。 Class c，不包括特定顺序的列表。

现在，您在 class A 中进行更改，该功能返回基于 object 的相同/其他属性以降序排序的对象。

在这里，class B 会说你改变了合同，需要调整它的进一步处理。

Class C 在这里没问题，因为它不关心排序。

因此，更改逻辑也会影响使用现有功能的客户端。 因此，在编写任何独立的模块/库时，版本控制已经完成。

Answer 3

您考虑耦合问题的方式不太正确。 这不是因为您更改了另一个模块而必须更改一个模块。 这是关于必须更改许多模块才能完成一项任务。

在松散耦合的环境中，每个模块都有一个定义明确的工作。 每个模块负责控制它的人的头脑中有一些事情，因此当有人想要一些小东西（大需求分解成小需求）时，只需更改一个或最多几个模块即可完成。

在高度耦合的环境中，每个模块的用途很难定义。 当它被记录下来时，文档会使用很多词，例如“帮助”或“允许其他模块”等。人们想要的实际事情是通过多个模块之间的协调行为来实现的，甚至知道一个模块的行为是正确的，你要考虑很多。

我希望你能明白为什么维护一个高度耦合的系统是一场噩梦，我希望你想写一个松耦合的系统来代替。

其中重要的部分之一是依赖于抽象。 这些抽象通常由接口定义，但重要的不是它们是接口，而是它们是抽象的。 制作一个高度耦合的系统很容易，其中一切都依赖于接口。 然后，当您必须进行更改时，您会发现除了使用它们的模块之外，您还更改了很多接口。

Answer 4

即使接口没有改变，实现也很容易打破你的期望，例如：

旧的实现方法

public void doStuff(){
    //real doing stuuf...
}

新的实现方式

public void doStuff(){
    throw new UnsupportedOperationException("Stop supporting doing stuff");
}

这就是为什么在升级依赖模块时需要进行回归测试

此外，您的依赖模块还有其他可能会中断的依赖项，例如使用 jackson 依赖项中断 lombok 更改

Answer 5

一个特别危险的依赖是如果一个类的内部实现在内部调用相同 class 的公共方法。

作为一个真实的例子（这个问题确实发生在 Collection 框架中， HashSet.addAll()与ArrayList.addAll()实现），想象一个addMultiple() Container有一些Integer的内部存储，有两个公共方法： addMultiple()和addSingle() ：

实施1

class public Container {
    private Integer[] storage = new Integer[0];

    public void addMultiple(List<Integer> numbers) {
        // Simple, but slow implementation
        for (Integer number : numbers) {
            // !!! Here is the hidden problem !!!
            addSingle(number);
        }
    }

    public void addSingle(Integer number) {
        storage = copyOf​(storage, storage.length + 1)
        storage[storage.length - 1] = number;
    }
}

现在，您想要添加一些功能，例如在将每个数字添加到容器之前将其乘以 2。 你决定像这样扩展Container class 的愚蠢方式：

class public DoubleContainer extends Container {
    @Override
    public void addSingle(Integer number) {
        super addSingle(number * 2);
    }
}

当Container具有实现 1 时，您实现了DoubleContainer 。它按您预期的方式工作，每个数字都是使用addSingle()或addMultiple()添加的天气加倍。

然后突然间，他们更改为实施 2。

实施 2

class public Container {
    private Integer[] storage = new Integer[0];

    public void addMultiple(List<Integer> numbers) {
        // New, improved, faster implementation
        int position = storage.length;
        storage = copyOf​(storage, storage.length + numbers.getSize())
        for (Integer number : numbers) {
            storage[position++] = number;
        }
    }

    public void addSingle(Integer number) {
        storage = copyOf​(storage, storage.length + 1)
        storage[storage.length - 1] = number;
    }
}

瞧：你的代码坏了。 通过addAll()添加的数字不会加倍。 所以你修复它：你也覆盖了addAll()方法：

class public DoubleContainer extends Container {
    @Override
    public void addMultiple(List<Integer> numbers) {
        List<Integer> doubledNumbers = numbers.stream()
            .map(number -> number * 2)
            .collect(Collectors.toList());
        super addMultiple(doubledNumbers);
    }

    @Override
    public void addSingle(Integer number) {
        super addSingle(number * 2);
    }
}

但是你也不能安然入睡——如果他们再次恢复到旧的实施呢？ 然后数字将翻两番......

如您所见，实现 2没有更改公共方法。 甚至可以有一个接口，它不改变大小写。

作为记录：不是我建议以这种方式使用 inheritance （更多信息，请阅读Joshua Bloch的有效 Java ，第 16 项：偏好组合而不是 Z5FED3411FAF832174EF1F040028 ） 您的问题是“如何更改 class 会影响另一个取决于 class。” 这是可能的答案之一。

Answer 6

其他答案中没有提到的东西......

如果Class A直接调用另一个class B的实现。 当Class B改变时，它必须重新编译，并且由于Class A与 B 直接耦合， Class A也必须重新编译。

这降低了两个类的独立部署能力。

这意味着，如果 B 被更改，则必须重新编译 A 才能正常工作。

这来自 Bob 叔叔，您可以在他的一篇博客文章Microservices 和 Jars中了解它。

Answer 7

假设您有两个类： Class A和Class B 。 假设Class A在其他字段中具有Class B的依赖关系，并使用 B 的一些计算：

class A {
  private C myC;
  private B myB;
  ...
  private void someMethod() {
    String foo = myB.bar();
    myC.setField(foo);
  }
}

如果您更改 B 中直接（或间接）影响bar()结果的内容，那么您可能会在A以及C内部产生各种影响。 这不一定是返回类型的更改，它可能导致A和C都依赖的错误计算。

请注意，此示例显示了紧密耦合，因此这些类中的任何一个都可能发生变化，这些变化很容易影响其他类，而您不必意识到。