2011-06-24 46 views
2

這是一個設計問題/討論。你會如何設計你的應用程序?通過繼承還是通過構成?

我創建了一個包含大約50個類的解決方案。

我通過引入包含類之間共享信息的新抽象類來重構類和刪除重複代碼,以便這些類從它們繼承。

E.g.

Abstract ColumnBuilder 
ColumnBuilderForDepartmentReport : ColumnBuilder 
ColumnBuilderForStoreReport : ColumnBuilder 

現在沒有我的設計包含很多類和重複代碼已被刪除這是一件積極的事情。

這是一個很好的設計?

我聽說我們應該更喜歡Composition over Inheritance。

它將如何應用於這種情況下,你想使用繼承來刪除重複的代碼?我應該重構代碼以使用Composition?怎麼樣?

感謝

+0

很多問題已經被問到這個問題:http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance,http://stackoverflow.com/questions/453738/inheritance-or-組成依賴於一個和一個... – Heisenbug

回答

1

你錯過了使用接口與組合 - 這給你組合的靈活性,但保留繼承的多態性。

E.g.你可以定義一個接口:IColumnBuilder,並且所有3個類都實現這個接口。

至於你的代碼是否設計得很好 - 無法從所提供的信息中分辨出來。很多課程並不是一件壞事 - 一段絃樂有多長?

我的經驗法則:

1)使用繼承時,你的子類「是一個」超類 - 在這個例子中你引用他們都列建設者這樣的繼承將是我的選擇。這使得添加新的列構建器類型變得更加容易。

2)使用組合,所有你想要實現的是代碼重用。 3)如果你想要獲得多態性,但是規則1不適用(不是「is-a」關係),那麼使用合成和接口。

+0

是的,我也用過接口;只是在這裏沒有提到它。我認爲界面會讓「有一種關係」(構圖)成爲可能。 –

+0

接口允許多態。即它們允許您將相關對象的集合分組並以相同的方式處理它們。但是,因爲您可以在單個對象中實現多個接口,所以您沒有受到「是-a」要求的限制。這意味着你可以使用接口和組合 - 一個不會促進另一個,它們是可以組合的獨立技術。 – BonyT

2

您需要兩者,因爲情況需要。組合是創建類的首選,但是當需要「是 - 某種」關係時,繼承是有意義的。

就你而言,這意味着繼承獨特的ColumnBuilder類型,然後可以通過組合使用其他類(用於'has-a'關係)。

例如,具有ColumnBuilder的Report類允許您分配您的唯一類(以及任何未來的ColumnBuilder繼承者),這要歸功於可繼承類類型的組合。

+0

這是一個非常好的解釋; 「是」和「有」來區分何時使用繼承組合。 –

+0

這對我來說很有意義!隨時upvote。 ;) – kiswa

1

我聽說我們應該更喜歡Composition over Inheritance。

一般很好的建議。但這並不意味着你應該全部替換它們。

如果你的子類需要超類中的所有內容,並且每個子類都增加了一小部分函數,​​那麼保留繼承就沒有問題。

它將如何應用於這種情況下,你想使用繼承來刪除重複的代碼?我應該重構代碼以使用Composition?怎麼樣?

您也可以使用組合來刪除重複的代碼。

您正在尋找的重構是Replace Inheritance with Delegation。使用谷歌搜索這個短語可能會找到一些比示例圖更詳細的參考資料,但你真的應該得到書Refactoring

相關問題