聚合泛化的使用

我有這個類模型，其中，銀行是一個現在正在計算機化銀行網絡的類。這必須有ATM（自動取款機）和人力出納。聚合泛化的使用

我用泛化，並已採取了一個名爲AccountHandlers它繼承銀行類類。 This AccountHandlers還有ATM和HumanCashier彙總到它。

現在的事情是，我的朋友爭辯說我把所有的事情都弄錯了。據他介紹AccountHandlers必須彙總到銀行和ATM和HumanCashier必須繼承到AccountHandlers。

我對此有點困惑。我如何模型呢！或者說這兩種方法都是正確的？

來源

2010-09-05 Nagaraj Tantri

我會回到基礎。

你應該問自己，如果一個ATM是AccountHandler，或者如果AccountHandler有ATM。這應該給你一個關於使用繼承或組合的問題的一般答案。

兩者都將是正確。只有一個是好的設計，這取決於你的應用程序試圖做什麼。

一般來說，有一條經驗法則（取自有效的Java），指出您應該贊成繼承繼承。用一點鹽做好，並確保你正確地設計你的應用程序。（更多信息參見Prefer composition over inheritance?）

來源

2010-09-05 11:00:02

感謝您提供有用的提示。我是這個模特兒的新手。 – 2010-09-05 20:52:49

如果它工作正確。不要因爲UML建模浪費時間而陷入困境。寫一個原型，任何設計缺陷都會很快顯現出來。

來源

2010-09-05 10:55:45 James

認真?? ??！在編寫原型時，設計缺陷並不總是很明顯，有時可能需要數週或數月時間才能變得明顯，並且花費大量時間來修復。 UML建模並不適合每個人，但在代碼中的設計缺陷會在幾個月後變得更明顯 - UML建模有助於確保您在第一次使用UML建模時儘可能地正確。 – slugster 2010-09-05 11:00:45

當然。這顯然是功課，已經有了混亂。如果我是這個人，我會試着先把它編碼出來，弄清楚爲什麼事情是這樣的，並從中制定UML。這將幫助他第一次得到他未來的UML（如果這種情況發生的話） – James 2010-09-05 11:16:36

我明白你想說的是什麼，但底線現在我甚至應該清楚地知道我如何以及爲我的關係選擇什麼一類。但是如果明天出現這種情況，我就會陷入我的代碼中，這意味着我需要再次改變我的設計。這就是爲什麼人們不願意浪費時間去改變設計中每個缺陷的設計，而是會創建一個具體的設計，然後繼續。 – 2010-09-05 20:46:39

通常繼承（或專業化）用於建模「是-一個」關係，而聚集/組合物用於「具有-一個」關係。

現在你可以問問自己哪一個是正確的：

帳戶處理是銀行或銀行有一個或多個賬戶處理
人類收銀員是一個（特殊的的）賬戶處理器或賬戶處理器有一個人收銀員

在我看來，大膽的陳述是正確的。所以你應該使用銀行 - >賬戶處理程序的集合或組合，併爲賬戶處理程序 - >人類收銀員使用繼承。

來源

2010-09-05 11:01:55 M4N

謝謝你給出一個很好的解釋 – 2010-09-05 20:53:45

請與您的領域專家溝通，並從他們的驗證模型。我認爲這是領域驅動設計的前幾章幫助的地方。您應該嘗試定義實體及其關係（是或是否），在白板上繪製它們並與您的領域專家討論。

儘管你做了什麼請寫你的實施圍繞單元測試。因爲有了這樣的混淆，你很可能會修改類的結構，那麼你的單元測試將確保你可以順利地重新分解代碼。

來源

2010-09-05 16:49:52

聚合泛化的使用

回答

相關問題