我應該使用哪種設計模式？

我有一段邏輯需要根據類型執行一次或多次（在一個循環中）。戰略模式在這裏有意義嗎？從本質上說：我應該使用哪種設計模式？

if (type == 1) 
{ 
    ProcessReport(""); 
} 
else if (type == 2) 
{ 
    for (int i = 0; i < numUsers; i++) 
    { 
    ProcessReport(userId); 
    } 
} 

public void ProcessReport(string id) 
{ 
    if (id == "") 
    { 
    //Send full report 
    } 

    else 
    { 
    GetReportFragment(); 

    //Send report 
    } 
}

來源

2012-01-10 DotnetDude

如果我沒有弄錯，使用Repository Pattern會不會更好？只是一個想法乍一看.. – MethodMan 2012-01-10 16:59:36

請注意，設計模式不是解決問題的答案，但它們是解決具體問題的方法。所以明智地使用它。在你的情況下，我沒有看到這種模式的原因。 – Zenwalker 2012-01-10 17:03:53

代碼段太短，無法提供明確的建議。在談論設計模式時，嘗試解釋您的問題，工作流程，行爲以更全面地瞭解問題會更有用。代碼中的一個'if/else'語句並不意味着您應該立即更改您的設計。 – Groo 2012-01-10 17:29:10

通常的策略模式定義一組算法，封裝每一個，使得它們可以互換。策略可以讓算法獨立於使用它的客戶端。

我沒有看到任何複雜的算法，其價值增加一些抽象

的另一層如果你想封裝ProcessReport行爲我會創建表示此行爲的接口，因此你可以叫IProcessReport.Process(userId)在環

來源

2012-01-10 16:58:57

您的代碼可以簡化爲這樣：

if (type == 1) 
    SendFullReport(); 
else if (type == 2) 
    for (int i = 0; i < numUsers; i++) 
     GetReportFragment(userId);

當然，你必須執行SendFullReport()和GetReportFragment(string userId)方法。

在這種情況下使用複雜的設計模式沒有意義。

來源

2012-01-10 17:02:42 GolfWolf

根據變量type的語義，使用多態可能有意義。

鑑於目前的例子可能是開銷（只有兩個分支），但每次你看到像if() ... else if() ... else if() ...或switch() { case: ... }你有時間的結構疑惑：會有多少個條件分支是什麼？未來可能會出現新的嗎？

根據這些問題的答案，我們可能決定做一個Replace Conditional with Polymorphism重構。

來源

2012-01-10 17:10:04 GolfWolf

所以，這只是一個例子，或者它是實際的大小？我的意思是，如果你有兩種類型，最好使用的模式是保持簡單:)。

如果你有幾種類型，那麼你可以在那裏有一個策略，或者一個字典類型委託/命令與你想要執行的代碼。

來源

2012-01-10 17:11:10 ivowiblo

這只是一個例子。實際的代碼太大，不能在這裏發佈 – DotnetDude 2012-01-10 17:14:31

好的，所以類型命令的字典就足夠了。如果這些命令太簡單了，那麼可以使用委託。 – ivowiblo 2012-01-10 17:16:21

好吧，既然您明顯使用「類型代碼」來區分不同的行爲，您可以從replacing it with subclasses (polymorphism)開始。這通常是在存在基於類型代碼的分支時首先要做的事情。

但是，對於簡單的問題，這可能是一個矯枉過正的問題。什麼是你的代碼更反感的是：

使用幻數你的類型：你至少應該將其更改爲枚舉以提高可讀性
傳遞空參數（""）指示特定行爲：至少爲「完整報告」創建單獨的方法，如果您沒有要指定的ID

來源

2012-01-10 17:13:35 Groo

儘管目前的功能有多簡單，但我覺得策略模式是正確的解決方案。總的來說，我避免了'if'語句並試圖將我的代碼進行原子化。 Groo對代碼'氣味'的觀察也是我的。多態（策略）可能看起來過度殺傷，但我寧願稍微抽象一點的解決方案，也不願嘗試根據希望爲空或字符串的字符串參數更改函數的行爲。

來源

2012-01-11 14:23:02

我應該使用哪種設計模式？

回答

相關問題