擴展方法與助手類

可能重複：
Extension Methods vs Static Utility Class 擴展方法與助手類

我建立的，其執行基於在.NET對象的動作一般功能的API。例如;我創建了一個函數來檢查一個字符串，看它是否是一個電子郵件地址。

我既可以有：

static bool IsEmailAddress(string text) 
{ 
    return IsMail(text); 
}

或者我可以創建一個擴展方法，將像這樣被使用：

string text = "[email protected]"; 
if (text.IsEmailAddress()) 
{ 
}

哪個更適合，或者你認爲，因爲這是一個通用庫，我可以在技術上實現這兩種方式，並允許開發人員決定哪些是最適合他們的？

來源

2012-07-04 series0ne

**順便說一句：**使用'返回IsMail（文本）'而不是if語句。 –

我會用擴展方法和重構Mahmoud建議。 –

我認爲'string'不是'電子郵件地址'的責任。所以我不認爲這應該是一個擴展方法。 – CodesInChaos

創建擴展方法意味着當用戶使用該類型時，它將在智能感知期間自動顯示。您必須小心，不要在開發人員瀏覽的方法列表中添加很多噪音（特別是在創建可重用框架時）。例如，當這些方法在某個上下文中可用時，您可能更適合使用「正常」靜態方法。特別是在實施一般類型的擴展方法時，例如string。

以擴展方法ToXml(this string)或ToInt(this string)擴展方法爲例。儘管使用這些擴展方法看起來相當方便，但將文本轉換爲XML並不是您在整個應用程序中將要執行的任何操作，並且它可以很容易地完成XmlHelper.ToXml(someString)。

只有一件事情更糟糕，那就是在object上增加一個擴展方法。

如果你正在編寫一個可重用的框架，the book Framework-Design-Guidelines by Krzysztof Cwalina是絕對必讀的。

來源

2012-07-04 13:57:07 Steven

不要忘記，擴展名綁定到名稱空間 - 所以直到您沒有在客戶端類中指定擴展名的名稱空間 - 您的擴展的方法的intellisense將不會出現。另一件事什麼擴展真的是什麼？ - 編譯之後 - 它是靜態類的靜態方法 - 所以我寧願使用擴展作爲語法糖，並且我的命名空間具有良好的結構，而不是創建StaticHelpers。 –