0

在设计应用程序时，您何时知道您的对象是紧密耦合的？紧密耦合的对象/代码的症状是什么？

4

5 回答 5

4

让我们取两个对象 A 和 B：

为简单起见，假设 A 具有以下性质

名称：字符串 年龄：整数 DateOfBirth：DateTime

B有以下方法：

CreateInstanceOfA(string Name, Integer Age, Datetime DateOfBirth) 并返回 A 的实例，其值已初始化为方法参数。

现在，假设您向 A 添加一个新属性：

状态码：字符串

现在你有问题了。您是否更新了 CreateInstanceOfA 以包含新属性？如果是这样，您必须在所有引用它的地方更改代码以包含新字段。如果您选择的语言支持运算符重载，您可以添加一个新方法。它可能不会破坏编译，但您仍然需要更新代码。更糟糕的是，您将使用旧方法，并且必须在创建后手动设置新属性。

儿子 A 和 B 确实是紧密耦合的。

这不是最好的例子，但它是一种快速查看设计更改可能产生的后果的方法

于 2012-09-03T21:37:39.090 回答
2

当您的设计中的一个小改动影响大量（可能与您的更改无关）类 时，您知道您的设计是紧密耦合的。

Class D是一个为其他类提供一些功能的类。
Class A,Class B并直接Class C使用。中的任何变化都会影响和。 现在假设我们想要增强以验证来自 class 的任何操作。在不影响的情况下是不可能的，并且我们不关心身份验证。由于新的需求，必须重构整个事情。
DABC
DABC

其他例子：直接访问数据库。使用的数据库中的任何更改都可能影响整个代码（例如，如果您在不使用 的情况下SQL全部执行语句）。您的业务逻辑不会改变，但切换数据库的新要求会影响您的所有代码DAO

于 2012-09-03T21:26:59.840 回答
2

经验法则是计算给定类引用了多少其他类。有几种方法可以查看：

  • 导入数 (Java)、使用数 (C#)、包含数 (C++) 等。
  • 类中的字段/成员变量数
  • 方法的参数数量
  • 间接类型引用的数量（例如a.getB().getC().getD()）

对任何这些类型的更改都可能导致紧密耦合的类也发生更改。

于 2012-09-03T21:53:43.503 回答
2

如果您的对象是，您可能会遇到紧密耦合：

  • 很难改变。症状：每次编写依赖项的新变体并希望与之通信时，都需要将 if 语句添加到类中。您的代码库有大量的 if 语句可能对全局变量进行操作，这使得调试和维护成为一场噩梦。

  • 脆弱。症状：对象中的错误可能会波及整个系统中意外数量的其他对象。由于依赖项之间缺乏明确的约定，因此很难预测您想要对对象进行的更改的后果。

  • 难以重复使用。症状：在不同的上下文中重用一个对象意味着拖拽它的所有依赖项及其细节，其中一些可能与新的上下文无关。

  • 很难测试。症状：您的自动化测试需要在执行任何操作之前将大量对象粘合在一起，这使它们变得非常缓慢。您的测试很脆弱 - 一个对象的细节变化会影响其所有依赖项的测试设置，并且它们很容易变红。

于 2012-09-04T15:56:13.640 回答
0

得墨忒耳定律解释了松散耦合的一些简单准则。

在实践方面，您还可以查看Lattix，这是一个 Eclipse 插件，可帮助您映射和重构依赖项

于 2012-09-03T21:56:25.800 回答