哪种设计支持低耦合？

Design #2

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

2011-04-20 user478636

第二个关注所有“智能”的注册，这看起来不错。 “支付与销售”只是“按照他们所说的去做”。在第一种情况下，责任更分散，也许更棘手。但是...不知道你如何实际测量整体低耦合！我也很乐意看到即将到来的答案。 :-) – 2011-04-20 18:10:13

我认为你可能会找到一本书（[在线查看]（http://books.google.co.uk/books?id=9CL446IzhuAC&pg=PA38&lpg=PA38&dq=events+chapter+one+coupling&source=bl&ots = qmJTOuCz90与SIG = EZKvZBjF8QmGohatC97HsmAqG0c＆HL = EN＆EI = wj6tTqe5LcTX8gON_YyiCw＆SA = X＆OI = book_result和CT =导致与resnum = 6＆VED = 0CEMQ6AEwBQ＃v = onepage＆q =事件％20chapter％20one％20coupling＆F = FALSE）） “基于事件的编程：服用事件到了极限 ” 不要以表面价值为标题 - 第一章给出了一个深刻的描述和方法，以减少/转移耦合到较少形式的耦合行为。 – 2011-10-30 12:23:37

在第一个付款与Sale结合。在第二个它与Register and Sale结合。我会说第一个有较低的耦合，因为Register没有付款的概念。付款可以完全消除，不需要更改注册。第二，如果您消除付款注册和销售将需要改变。

来源

2011-04-20 18:19:18 nsfyn55

从创作者的角度来看，一个注册记录付款。所以它包含有关付款的信息。那么从定义上讲，它应该创造付款不？ – user478636 2011-04-20 18:38:28

那不相关。如果您摆脱了所有注册，付款和销售，请用Object1，Object2和Object3替换它们。我会说一个是最分离的。绘制一个简单的依赖关系图并计算行数。方式2 - 注册取决于销售和付款。销售取决于付款 - >多数民众赞成在3线。方式1 - 注册取决于销售，销售取决于支付 - >多数民众赞成在2.小于3，所以有较少的耦合 – nsfyn55 2011-04-20 19:04:38

“在计算机科学中，耦合或依赖是程度模块依赖每个程度其他模块“。 – nsfyn55 2011-04-20 19:07:15

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

在第二个

存在与依赖注入低耦合 - http://en.wikipedia.org/wiki/Dependency_injection，女巫是一个设计图案分离依赖解析行为，从而解耦高度依赖组件。在第一张照片中，Payment和Sale高度依赖。

来源

2011-04-20 18:06:29 dantuch

我不知道我是否同意这一点（原因很明显:)）。 DI或没有DI不会使设计更多或更少耦合。在这种情况下，其中一个类需要实时实例化付款。即使您使用DI，也可以降低销售额中的全额付款。这似乎是一个更明智的设计将登记acceptPayment（p）和创建一个销售，但它不是我的注册 – nsfyn55 2011-04-20 18:32:04

注册应该是委托此任务销售，否则注册将成为incohesive – user478636 2011-04-20 18:39:53

@ nsfyn55你说DI不'（让设计或多或少耦合）:)我说它是这样的 - DI Paymant可以重用......它甚至可以有一个实例;） – dantuch 2011-04-20 18:41:36

我在第一个例子中看不到这一点。注册是不需要的？

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

来源

2011-04-20 18:51:54 jgauffin

哪种设计支持低耦合？

回答

相关问题