2010-02-11 73 views
5

我在創建課程時多次問過自己這個問題,尤其是那些涉及館藏的課程,但我從來沒有想出滿意的答案。這是一個OOP設計問題。我應該實例化一個集合還是從集合繼承?

例如,在支票簿註冊程序中說我有一類BankAccount。 BankAccounts包含的數據涉及賬戶名稱,賬戶類型(檢查,保存,枚舉的枚舉)以及其他數據,但最重要的是賬戶中的賬戶(存款或取款)的集合。

在這裏,我有保持調整的集合兩種選擇:

  1. 實例化的集合,並將其作爲BankAccount類中的一員。這就像是說「BankAccount 一系列調整」。
  2. 繼承集合。這就像是說「BankAccount 調整集合。」

我認爲這兩種解決方案都很直觀,當然,兩者都有一些優點和缺點。例如,實例化允許類(僅允許單個基類的語言)從另一個類繼承,而從繼承繼承的類可以很容易地控制Add,Remove和其他方法,而無需編寫代理方法來「包裝'那些。

那麼,在這種情況下,哪種方法更好?

+0

看看這篇文章:http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html 它描述了繼承如何降低可維護性。 – Ozan 2010-02-11 17:44:09

回答

8

對我來說,一個銀行賬戶一個調整的集合。銀行賬戶不是調整的集合,因爲它「是」遠不止於此:它也是「是」的名稱和類型等

所以,你的情況(以及類似的情況下),我建議你在你的班級裏彙總一個集合。

如有疑問,請避免繼承。 :-)

我可以進一步爭論。爲了正確使用繼承,子類必須滿足Liskov's substitution principle;這意味着,在您的情況下,BankAccount應該是預計在Collection任何位置的有效類型。我不認爲是這種情況,因爲Collection可能會暴露諸如Add()Remove()等方法,而您希望對您的銀行帳戶中的添加和刪除調整施加一些控制,而不是讓人們自由添加和刪除它們。

2

個人而言,我會說BankAccount集合Adjustment。它可能會有其他的財產不完全是關於什麼已經存入或提取(客戶,銀行賬戶類型等)。

在設計方面,我的BankAccount對象會暴露類型爲Adjustments的延遲加載屬性。

就代碼中的使用而言,我會實例化銀行賬戶,如果我需要知道進出賬戶的內容,我會使用公開的屬性。BankAccount將是主要目標,負責提供僅與實例化帳戶相關的調整。

2

實例化,當然。

我同意其他海報關於銀行帳戶是「更多」而不僅僅是其他項目的集合。 或者,也許你只是選擇了一個真正叫喊「實例化」的例子。

例子:

  • 如果您的銀行帳戶需要完全不同的項目,第二個集合會發生什麼? (例如:收集可以操作的人,如夫妻,例如收集信用卡,PayPal賬戶或其他任何可以在您的銀行賬戶上「運作」的人)。
  • 根據語言的不同,集合會暴露出太多的信息:如果另一個對象需要訪問Adjustements ...假設您在網頁上顯示您的移動歷史記錄,則會自動將您的「集合」用於注入,刪除等操作。
0

我覺得過度地陷入像「這更多是 - 一個還是一個 - 」有點危險 - 在一天結束時,重要的是您的設計如何解決問題,它是如何可維護的等等。事實上,我個人理解面向對象編程的一個轉折點就是放棄了「作爲名詞的對象」。當你深入研究它時,對象就是一個從函數向上的抽象,沒有什麼更多或更少。

這是一個很長的路要說「有」。 :-)子類很複雜,使用起來很簡單。

+0

「你的設計如何很好的解決了這個問題」==「語義學」 – CesarGon 2010-02-12 00:11:16

+0

好吧。我的意思是,像「這似乎更像是一個概念上的關係船」這樣的元問題很危險。實用性占主導地位。 – Ken 2010-02-12 01:15:58

+0

我不同意。 :-)對我(和我的大多數同事)來說,「元問題」是最重要的。他們直接問題的核心,因此他們駕駛練習。僅靠實踐經常會繞過更深的問題。一位偉大的開發人員能夠深思這些更深層次的問題,並且即使在沒有意識到的情況下也能夠利用他/她的「元數據」能力,從而獲得以良好理論爲基礎的重大實踐成果。 – CesarGon 2010-02-12 20:37:12