2009-12-14 32 views
2

我有一個設計模式問題。 我有一個類似於CAB(複合應用程序塊)的我們的智能客戶端應用程序的框架,我們稱之爲widget-framework。 我們可以將應用程序的模塊定義爲「Widget」,並且有一個配置文件列出了所有的小部件。 小部件是實現IWidget接口的任何類。 所有的小部件都有加載子小部件的代碼,並且代碼是相同的。 如何在所有這些小部件之間共享該代碼,而不強制小部件從具體類繼承? 這種情況下的最佳做法是什麼? 這種情況下有設計模式嗎?如何刪除實現接口的所有類的重複代碼,而不從具體類繼承?

由於

回答

1

這聽起來像Decorator pattern可以使用到「負荷子窗口小部件」的方法添加到每個類。該模式允許'load sub-widgets'方法在不依賴繼承的情況下針對不同的類進行更改。

0

聽起來像使用從接口繼承的抽象類的完美可能性。但似乎沒有理由不這樣做。

您可以生成一個封裝所有窗口小部件類的重複代碼的類,然後在每個窗口小部件中創建該類的一個對象。現在代碼只在一個類中,但是每個小部件都可以從他自己的對象調用函數來使用重複代碼的功能。

0

我會做聚合。製作一個WidgetLoader類,並在內部使用它來實現您的子控件加載功能。

這樣可以使您的Widget類的主要意圖分離的加載功能,避免了繼承,並且可以由鬆散耦合如果通過工廠實例化。

0

如果你不希望延長超類的通用代碼,你可以嘗試使用代表團和包裝通用的功能,讓我們把它叫做SubWidgetLoader。這就是創建一個實現常用功能的類,並讓您的IWidget對象包含SubWidgetLoader。這樣,每個單獨的Widget就不必重複代碼,而是調用SubWidgetLoader類來執行作業。

2

可以使用複合材料的方法,使被稱爲SubWidgetLoader或類似物體,然後進行iWidget中的所有實例包含裝載機類的一個實例。

0

爲什麼你不會繼承基類?

您的情況似乎很適合template method pattern。我認爲繼承是最好的解決方案,除非有充分的理由不這樣做。在你的具體情況下,從BaseWidget繼承似乎也是合乎邏輯的步驟。

注:我知道你特別要求如何不使用繼承,但你不告訴我們爲什麼。我認爲,如果有人特意要求某些與我通常的軟件開發傾向相反的東西,他不僅應該解釋原因,還應該解釋爲什麼,如果他不拒絕簡單地提供答案(如果我知道的話),如果我認爲只是「設計」是錯誤的。

+0

他試圖避免因* *混凝土基類繼承。這是一個好主意,因爲從一個具體的類繼承是固有的脆弱。基類不知道它的內部實現可能正在被依賴。這是一個風險 - 如果基類實現發生更改,您的繼承類可能會中斷。見例如http://en.wikipedia.org/wiki/Fragile_base_class。 – 2009-12-14 16:43:07

+0

嗯,我明白了......沒有一天你不會在stackoverflow中學到新的東西......但模板方法模式特指從基本抽象類繼承,而不是具體的。 – 2009-12-14 18:05:22

0

爲什麼避免讓它們都來自一個共同的基類?它可能是一個抽象基類,因爲你擔心它們不是從具體的基類繼承的。抽象基類可以提供它們都共享的「加載子小部件」功能。

但是,如果你想避免繼承,那麼Builder模式看起來像是一個很好的重用構建子部件樹的代碼而不引入基類的代碼。

http://en.wikipedia.org/wiki/Builder_pattern

0

在其他語言中,這可能與混入來實現。在C#中,你可以得到的東西通過定義接口擴展方法關閉...

interface IWidget 
{ 
    ICollection<IWidget> SubWidgets { get; set } 
} 

static class WidgetExtensions 
{ 
    static public void LoadSubWidgets(this IWidget widget) 
    { 
     widget.SubWidgets.Add(GetSomeWidgetDependency()); 
    } 
} 
+0

免責聲明:正如其他人所說,從一個抽象基類繼承會更好。我只是提供另一種選擇.. – MattDavey 2011-05-09 08:11:35

相關問題