哪种设计支持低耦合？答案

【问题标题】：Which design supports low coupling?哪种设计支持低耦合？
【发布时间】：2011-04-20 18:02:01
【问题描述】：

哪种设计支持整体低耦合？为什么？

【问题讨论】：

第二个将所有“智能”集中在寄存器中，这看起来不错。然后付款和销售只是“按他们说的做”。在第一种情况下，责任更加分散，而且可能更棘手。但是......不确定您如何实际测量整体低耦合！我也会有兴趣看到即将到来的答案。 :-)
我想你可能会找到一本书 (view it online) “基于事件的编程：将事件发挥到极致” 不要只看书名——第一章给出了深刻的描述和减少/转移耦合到较小形式的耦合行为的方法。

【解决方案1】：

在第一个付款与销售相关联。在第二个中，它与注册和销售相结合。我会说第一个耦合度较低，因为 Register 没有支付的概念。付款可以完全消除，无需更改注册。在第二个中，如果您取消了付款，则注册和销售都需要更改。

【讨论】：

从创建者的角度来看，A 寄存器记录了付款。所以它包含有关付款的信息。所以根据定义，它应该创建付款号？
那不相关。如果您去掉了所有的 Registers、Payments 和 Sales，请将它们替换为 Object1、Object2 和 Object3。我会说一个是最解耦的。画一个简单的依存关系图并计算线数。方式 2 - 注册取决于销售和付款。销售取决于付款-> 那是 3 行。方式 1 - 注册取决于销售，销售取决于付款 --> 即 2。2 小于 3，因此耦合较少
“在计算机科学中，耦合或依赖是每个程序模块依赖于其他模块的程度。”

【解决方案2】：

在第一个Payment 是由Sale 创建的，所以这更加耦合。

在第二个中，依赖注入的耦合度很低 - http://en.wikipedia.org/wiki/Dependency_injection，witch 是一种将行为与依赖解析分离，从而解耦高度依赖的组件的设计模式。 Payment 和 Sale 在第一张图片中高度依赖。

【讨论】：

我不确定我是否同意这一点（出于显而易见的原因:)）。 DI 或没有 DI 不会使设计或多或少耦合。在这种情况下，其中一个类需要即时实例化付款。即使您使用 DI，将全部付款封装在 Sale 中也会降低耦合度。似乎更明智的设计是注册 acceptPayment(p) 并创建销售，但它不是我的注册
Register 应该是这个任务委托给 Sale 的人，否则 register 将变得不连贯
@nsfyn55 你说 DI 没有（使设计或多或少耦合）:) 我说它有 - 使用 DI Paymant 可以重复使用......它甚至可以有一个实例；）
那不是耦合。第二种支持的耦合形式称为内容耦合。 “内容耦合意味着改变第二个模块产生数据的方式（位置、类型、时间）将导致改变依赖模块。”。在两个中，销售和注册都是与支付 API 耦合的内容。在一个唯一的销售是。你有多少个实例是无关紧要的。 DI 与接口结合可用于将客户端类与实现分离，但在这种情况下没有接口。
简单的答案是，如果您摆脱 Payment，哪一个需要更多的代码更改。无论如何，答案都是第二个，因为在第二个中有两个付款接触点。

【解决方案3】：

我看不出第一个例子的重点。不需要注册？

在第二个示例中，可以使用任何类型的付款。（签证、现金等）。因此，它的耦合更松散。

【讨论】：