architecture - 有哪些技术可以在保持松散耦合的同时增加内聚力？

Question

Loose coupling, high cohesion for a maintainable application

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

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

但是，我觉得我从未真正听到过任何关于增强凝聚力的具体建议。有人可以提供吗？

您可以从那里开始回答，但我也有具体的情况需要建议。

---

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

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

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

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

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

Answer 1

内聚意味着您不会将不相关的东西放在模块(类，...)中。从你的描述来看，你似乎做得很好。适当的测试(您似乎也在这样做)应该可以控制风险。

您可能可以使用类型系统(泛型/模板)来确保信息及其验证器能够组合在一起，并可能节省一些代码/使其更加统一(不过，请确保增加的复杂性是值得的)。

否则继续努力。