在高耦合环境中,更改一个模块会影响另一个模块。好的,但我看不出这怎么可能(除了更改方法签名或返回类型)?
好吧,如果我改变一个类,那么它只能在以下情况下破坏其他类中的代码:
出于同样的原因,依赖抽象(接口(interface))是很好的,这样我们就可以保证定义的方法会在那里。
除此之外,更改一个类还能如何影响另一个依赖类?
最佳答案
即使这被标记为“Java”,我也会给出一个更广泛的答案。
耦合用模块 A 在使用模块 B 时做出的假设来表示。模块 A 做出的假设越多,它与模块 B 的耦合就越多。
一个模块的 API 基本上是它的消费者可以做出的一组假设。返回类型或方法签名只是编译器可以验证的假设。
例如,SimCity was coupled with Windows 3.x memory allocator .内存分配器有一个契约(Contract),说你可以假设 X、Y 和 Z,就是这样。不能假设任何其他行为。但 SimCity 假设了这一点,因此,他们无法更改 Windows 95 中的内存分配器(嗯,不是在 SimCity 执行时)。
显然这不是有意的耦合——任何关于模块超出其接口(interface)的假设都应该是无意的,但这仍然是一个假设。
其他示例包括:
关于oop - 耦合 - 除了更改方法签名或返回类型之外,更改一个模块如何影响另一个模块?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/58820466/