如何判断软件是否高度耦合？

我对术语“高度耦合”很熟悉，但是很好奇是否存在迹象（代码气味）可以表明代码高度耦合。我目前正在使用Java EE，但这可以应用于任何语言。

编辑：

如果有人感兴趣，这篇文章听起来很有帮助：追求代码质量：当心这对夫妇！（IBM）

在我看来，模块耦合不良的首要指标是双边依存关系。例如，Module1调用Module2中的某些功能，而Module2调用Module1中的某些功能。

大多数接口应该是单向的。如果被调用的模块需要将某些信息传递给未作为调用的一部分返回的调用模块，则它应使用某种消息传递或事件触发机制，例如消息队列。理想情况下，应该在某些初始化或注册过程中传递消息传递接口的句柄。这样就完全抽象了接口，使得模块实际上并不关心事件的源头，因此将事件解耦。

另一个指示是当一个模块不断为某个特定数据集调用另一个模块时。这应该使您质疑谁应该真正拥有数据集。为什么该模块总是需要查看属于其他模块的数据？

可以这么说的第三个工具是问自己：“我可以拔出该模块并更换它，而无需更改其他模块。

这绝不是一个详尽的清单，但它们是我在设计软件时问自己的三件事。

过去的设计说法是：“您可以触摸朋友，也可以触摸私人。但是您不能触摸朋友的私人。” 简而言之，这就是耦合。

高度耦合的代码的标志包括非常大的接口，这些接口使人们知道实现的私有细节，以及看起来“彼此了解很多”的对象。有一些自动分析工具会标记看起来与您紧密耦合的代码。见http://www.scitools.com/features/metricsintro.php一个随机一个。（我不知道它的效果如何。在Google搜索中它的出现率很高。）

尝试为类编写一些单元测试。如果您无法轻松地测试类而又无需创建/模拟支持类或db / ui的负载，那么这肯定是不良耦合/依赖性的标志。

它也是最好的解决方法之一，但是您必须在编码过程中（例如TDD）这样做，以使您诚实。

对我来说最明显的迹象是，一切都是公开的。

另一个迹象是违反了Demeter法则-在非流利接口上过多了this.SomeObj.SomeProp.SomeProp引用。

我曾经看到过我自称为“ puppetmaster类”的内容，该类可即时构建数据输入表单。它还有其他几个违反软件设计的行为，因此，过多的耦合是其最小的担忧。

当从其创建的控件中检索数据时，它的操作如下：

var control = activeDataEntryControl as CustomTextBox;
if (control != null)
   result = control.NestedTextBox.Text;

/* several other controls */

该涟漪效应。

每次更改都会对所有紧密耦合的模块产生连锁反应。

违反了“打开-关闭”原则，因为它没有正确关闭并且更改泄漏。

检查类/包/ dll / jars / whatnots之间的＃include / imports等数量。尝试在精神上，手动或使用某种工具绘制图形。

• 如果该图是密集的（即，到处都是许多连接），则您的系统是单块的且高度耦合。
• 如果将其清楚地分为几层，而跨/低层之间没有任何连接，并且连接很少，则说明您具有模块化和解耦的系统。

如果由于不知道具体责任在哪里而无法实施某项功能，则说明您的系统过于紧密。

对于非常基本的标志，您可以考虑查看不同包的类之间的接口数量及其用法（通常，松散耦合的代码包含接口，并且不同包中的各个类之间的直接交互作用有限），可以使用用于对其他类进行分组（在松散耦合的代码中，具有不同工作的类之间的实际交互作用是通过接口函数或通过更常见/分组的类的函数完成的）或在类内部对公共变量进行编号（松散得多，更少/甚至没有公共变量） ）。

几乎所有的代码气味都以某种方式指示了多余的耦合。我想虽然最能表明耦合的气味可能是“不适当的亲密感”（我最喜欢的气味）。

我认为另一种合理的测量方法是对UML图中的线进行计数。如果您有N个对象，并且它们之间有N ^ N条（或更多）行，那么您的代码将达到最大程度的耦合。N行可能会尽可能地少。