2012-03-24 48 views
0

請不要評論這裏使用的壞習慣。我只是試圖用易於描述的例子來解決這個場景的抽象問題。抽象挑戰。如何實現這一目的的封裝

我想模擬一個系統,它允許用戶輸入一個名爲TASK的實體與特定的配置參數,然後讓TASK執行特定於該任務的操作。

的任務定義一些例子可以是:
*創建目錄{PATH}文件{文件名}。
*將{源目錄}中的文件{文件名}複製到{目標目錄}。
*打開{記事本應用程序},輸入文本{示例文本}並將文件保存爲{文件名}。
*打開{sample.docx},在第二段末尾鍵入文本{sample text}。

每個任務都有一個描述性名稱和最多5個參數。在上面的例子中,參數用大括號{}括起來。用戶將被指示繼續上述任務,我們的應用程序將驗證它們是否已完成。每個任務必須具備以下功能:

在靜態的世界裏,我將創建下列類:

public abstract class TaskBase { public abstract void Perform(param1, ... param5); }
public class TaskFileCopy: TaskBase { public override void Perform(param1, ... param5) {} }

的問題是,任務可能是幾乎任何東西和程序後,編譯和部署,需要添加更多的任務。首先想到的就是繼續從TaskBase派生出來,實現Perform,重新編譯和重新部署,同時保持以前的任務結果的完整。

這裏有兩個問題:當我們碰到2000個任務時,我們將有至多2,000個派生類,其次,底層的OODB將陷入困境。

我一直在想System.AddIn,但我確信這種情況在OOP設計中有更好的解決方案。

回答

0

我懷疑System.AddIn適合這種事情。恕我直言,System.AddIn用於更多靜態API,不適用於將要迅速擴展的某些內容。也許你可以看看MEF而不是簡單的,它基於可擴展性和組成。

正如你所說,繼承也不是要走的路,因爲擁有2000個派生類將是一場噩夢。

我認爲你應該尋找基於組合而不是繼承的設計模式。其中有幾個。其中之一是Composite模式。有了這種模式,你可以有一些非常簡單的可重用任務,你可以將其組合成更復雜的任務。您可以擁有包含子任務的任務,其中包含子任務等等。

你也可以看看可以在DLR上託管的動態語言。像IronPython。你可以創建一個腳本庫。每個腳本都有一個任務

同樣爲了靈感,你可以看看Windows Workflow Foundation,特別是活動。

什麼是顯而易見的是,你需要最大限度地重用。當然這說起來容易做起來難。

祝你好運,祝你好運。

+0

嗯...現在我堅持繼承,直到任務數量增加。除了你的建議,我還考慮存儲代碼或編譯模塊,並使用反射來在運行時執行它們。我需要更好地理解MEF。複合模式可能是一個候選人,但是這讓我有點害怕,知道這些任務可能有多種多樣。 – 2012-04-06 03:59:14