问题标签 [cohesion]

得墨忒耳法则表明你应该只与你直接知道的物体交谈。也就是说，不要执行方法链接来与其他对象对话。当您这样做时，您正在与中间对象建立不正确的链接，将您的代码不恰当地耦合到其他代码。

那很糟。

解决方案是让您知道的类本质上公开简单的包装器，将责任委托给与之有关系的对象。

那挺好的。

但是，这似乎导致班级凝聚力低。它不再只是简单地负责它所做的事情，而且它还具有某种意义上的委托，通过复制其相关对象的接口部分来降低代码的内聚性。

那很糟。

真的会降低凝聚力吗？是两害相权取其轻吗？

这是发展的灰色地带之一，您可以在其中讨论界限在哪里，或者是否有强有力的、有原则的方法来决定在哪里划定界限以及您可以使用什么标准来做出决定？

我试图告诉某人他的代码不是“连贯的”，因为它有多种用途。我认为我不能很好地解释它，所以我正在寻找一个好的参考和/或定义。

我正在制作的游戏有 2 个课程，

gui 类和 logic 类，用于三分球游戏。GUI 类有一个使用 JButtons 数组的方法，并使用相同的匿名内部类动作侦听器将它们全部返回

问题是这样的，当我单击按钮时，我希望文本更改为取决于播放器 1 或 2 的 x 或 ao，但是这段代码应该在逻辑类中，不应该这样，所以我应该在逻辑类并从 make 按钮方法的匿名内部类动作侦听器调用它。但是，逻辑类不应该有对 gui 的引用，因为 gui 有对逻辑类的引用，

我想不出一个体面的解决方案

谢谢

松散耦合，高内聚，可维护的应用程序

这是我一遍又一遍听到的战斗口号。关于如何松散耦合组件有很多建议。

• 基于接口并注入所有依赖项
• 使用事件
• 使用服务总线
• 等等

然而，我觉得我从来没有真正听到过任何关于增加凝聚力的具体建议。有人可以提供吗？

你可以在那里开始回答，但我有一个具体的情况，我也想得到建议。

我有一个相当松散耦合的 C# Windows Forms MVP 应用程序，它的许多组件都基于接口，通过构造函数注入它们并使用控制反转容器 (Castle Windsor) 将它们组装在一起。

我会说它的架构非常好——它已经经历了几个大的变更请求并且很容易处理它们。总的来说，我对它非常满意，但我不能放弃一个挥之不去的怀疑，即它不是特别有凝聚力。作为唯一的开发人员，这对我来说不是问题，但我担心对于第一次进入应用程序的人来说，这会让人感到非常困惑。

让我举个例子 - A 公司使用该应用程序来填充和处理装满产品的外运卡车。这意味着有一个OutgoingTransactionInfo对象、一个OutgoingTransactionInfoControl（用于实际输入所述信息）、OutgoingTransactionValidator和OutgoingTransactionPersister。随着应用程序投入生产，我们也收到了处理传入事务的请求——这些事务附加了不同的信息、不同的验证以及不同的持久化方式。然后公司 B 也想将应用程序用于他们的事务处理，这个想法是相似的，但同样，信息、验证、持久性以及其他一些组件可能不同。

因为我的应用程序有一个很好的测试套件并且是松散的，所以我能够很容易地适应这些请求。但是，我认识到很容易意外地将其配置为无效状态。例如，您可以连接它以使用OutgoingTransactionInfo对象，同时使用IncomingTransactionValidator进行验证。如果差异很小，则错误甚至可能在一段时间内未被发现。

你对我有什么建议吗？您使用了哪些技术来降低此类风险？

我有以下方法和接口：

因为规则具有优先级，所以它们实际上不应该被乱序处理。这导致我（我认为）三个解决方案：

1. 在将规则传递给评估器之前对其进行排序。
2. 将参数类型更改为强制排序顺序的东西。
3. 在评估器中排序。

我喜欢选项 3，因为它始终确保它是有序的，我喜欢选项 1，因为它看起来更有凝聚力。选项 2 似乎是一个很好的折衷方案。

像这种上下文这样的场景是特定的/主观的，还是真的有一个最佳实践可以在这里应用？

什么是内聚和解耦？我找到了关于耦合的信息，但没有找到关于解耦的信息。

我正在制作一个简单的 3D CAD 软件。在类图中，许多对象需要通过 (x,y,z) 与其他对象进行区分。我创建了一个所谓的“位置”类，但问题是它看起来高度耦合，因为许多类都使用位置。有任何想法吗？

我现在正在学校学习编程和软件设计以及 Java。让我混淆的课程是软件设计。我们正在使用 Word 运行简单的 VB 代码来做简单的程序。我的教练说我使用运行总数正在失去凝聚力。我很难想办法避免它们。这是我正在谈论的一些伪代码的示例（这些模块被称为来自未显示的驱动程序模块）：

基本上DiscountPrice是用来连接前两个模块，然后DeliveryPrice是后两个。据说，最后一个模块甚至可能不需要在那里，我解决了这个问题。对初学者有帮助吗？

想象一下，你 90% 的工作只是在一个非常庞大、非常破碎的网站上对问题进行分类。想象一下，这个网站是用你所见过的最紧密耦合、最不内聚的 PHP 代码编写的，这种代码类型会将原始开发人员添加到你的“一见钟情”列表中。想象一下，这个 Web 应用程序由 4 个非常不同的部分（1 个商业部分、2 个“重新利用”和 1 个定制部分）和一大堆虚拟胶带和垫片组成。想象一下，它包含一种编程实践，其中网站的主要组件实际上依赖于无法正常工作的东西，而修复这些损坏的东西通常会破坏其他东西。想象一下，您从太多糟糕的经历中了解到，更改网站中看似无害的部分，例如拆分“名称” 字段分为两个单独的“第一个”和“最后一个”字段，这将使网站陷入瘫痪，需要数小时的回滚、合并和补丁。想象一下，多年来一直恳求客户放弃代码并重新开始，但却遇到了企业级的绝望和绞尽脑汁。然后想象一下获得 ASAP/EMERGENCY 票来实现在任何其他网站上需要 4 小时的新功能，但您对这个网站了解得更好，所以您报价 40 小时，然后按此收费并收取 80 小时的费用，但这没关系，因为客户习惯了他们的网站。想象一下，多年来一直恳求客户放弃代码并重新开始，但却遇到了企业级的绝望和绞尽脑汁。然后想象一下获得 ASAP/EMERGENCY 票来实现在任何其他网站上需要 4 小时的新功能，但您对这个网站了解得更好，所以您报价 40 小时，然后按此收费并收取 80 小时的费用，但这没关系，因为客户习惯了他们的网站。想象一下，多年来一直恳求客户放弃代码并重新开始，但却遇到了企业级的绝望和绞尽脑汁。然后想象一下获得 ASAP/EMERGENCY 票来实现在任何其他网站上需要 4 小时的新功能，但您对这个网站了解得更好，所以您报价 40 小时，然后按此收费并收取 80 小时的费用，但这没关系，因为客户习惯了他们的网站。

以下是您还应该想象的其他一些事情：

• 现在根本没有测试
• 有 googleteen 不同的登录层。有些客户实际上对网站的不同部分有 3 个不同的帐户
• 当我说“紧密耦合”时，我的意思是 include/require 语句的循环可能会像凯尔特结一样映射出来
• 当我说“最不凝聚力”时，我的意思是有些东西的组织方式有点像 MVC，但它并不是真正的 MVC。在某些情况下，您可能需要几个小时才能了解 URI A 是如何映射到文件 B 的
• UI 写得像“突兀”和“不可访问”是当时的流行语

想象一下，是否值得尝试达到中等水平的测试覆盖率？或者你是否应该，在这个想象的场景中，继续尽你所能用你得到的东西，希望，祈祷，甚至牺牲，客户会同意在这些日子里重写，然后你就可以开始写作了测试？

附录

自从你们中的许多人提出以来：我已经接近了在我必须约会的每一次机会中重写的可能性。与我一起工作的营销人员知道他们的代码是垃圾，他们知道这是他们最初选择的“最低出价”公司的错。我可能已经超越了我作为承包商的界限，指出他们花了一大笔钱在我身上为这个网站提供临终关怀，而且通过从头开始重新开发，他们会很快看到投资回报率。我也说过我拒绝按原样重写网站，因为它并没有真正做到他们想要它做的事情。计划是重写 BDD 风格，但将所有关键玩家集中在一个地方很难，我仍然不确定他们是否知道自己需要什么。无论如何，我完全希望这是一个非常大的项目。

感谢您迄今为止的所有反馈！

我正在阅读 Robert Martin 的 Clean Code，其中他提到代码具有高度凝聚力：

类应该有少量的实例变量。一个类的每个方法都应该操作一个或多个这些变量。一般来说，一个方法操作的变量越多，该方法对其类的凝聚力就越大。每个方法使用每个变量的类是最大内聚的方法是最大内聚的

但是当我们尝试编写并发代码时，我们努力将变量的范围限制在单个方法中以避免竞争条件。但这会导致代码的凝聚力最低。

在设计应用程序/类时，您应该更喜欢什么 - 内聚或并发？