哪種設計支持低耦合？

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

哪種設計支持低耦合？

回答

相關問題