什麼時候在C＃中使用靜態類

這個問題已經在這裏有了答案：

• 單一方法上課-最佳方法？ 14個答案

這是MSDN在「 什麼時候使用靜態類」下必須說的 ：

static class CompanyInfo { public static string GetCompanyName() { return "CompanyName"; } public static string GetCompanyAddress() { return "CompanyAddress"; } //... }

對於與特定對象無關的方法，請使用靜態類做爲組織單位。 一樣，靜態類可使您的實現更簡單，更快捷，由於您沒必要建立對象來調用其方法。 以有意義的方式組織類內部的方法（例如System名稱空間中Math類的方法）頗有用。

在我看來，該示例彷佛並未涵蓋靜態類的不少可能的使用場景。 過去，我已經將靜態類用於相關功能的無狀態套件，可是僅此而已。 那麼，在什麼狀況下（也不該該）將類聲明爲靜態？

---

#1樓

靜態類很是有用，而且有位置，例如庫。

我能夠提供的最佳示例是.Net Math類，這是一個包含數學函數庫的System命名空間靜態類。

就像其餘任何事情同樣，使用正確的工具完成工做，不然，任何事情均可能被濫用。

徹底否認靜態類是錯誤的，不要使用它們，或者說「只能有一個」或沒有，與過分使用它們同樣是錯誤的。

C＃.Net包含許多與Math類同樣使用的靜態類。

所以，若是實施正確，它們將很是有用。

咱們有一個靜態TimeZone類，其中包含許多與業務相關的時區函數，所以無需建立該類的多個實例，就像Math類同樣，它在靜態類中包含一組全局可訪問的TimeZone實現的函數（方法） 。

---

#2樓

對於C＃3.0，擴展方法只能存在於頂級靜態類中。

---

#3樓

我僅將靜態類用於輔助方法，可是隨着C＃3.0的出現，我寧願將擴展類用於這些方法。

因爲不多使用單例「設計模式」的相同緣由，我不多使用靜態類方法。

---

#4樓

我在較早的Stack Overflow答案中寫下了對靜態類的想法： 使用單一方法的類-最佳方法？

我曾經喜歡用靜態方法填充的實用程序類。 他們對輔助方法進行了很好的合併，不然將致使冗餘和維護麻煩。 它們很是易於使用，無需實例化，無需處理，只是忘了忘了。 我想這是我第一次嘗試建立面向服務的體系結構-許多無狀態服務只是完成了本身的工做而已。 可是，隨着系統的發展，巨龍將會來臨。

多態性

假設咱們有一個方法UtilityClass.SomeMethod，它愉快地響起。 忽然，咱們須要稍微更改功能。 大多數功能是相同的，可是咱們仍然必須更改幾個部分。 若是不是靜態方法，咱們能夠製做一個派生類並根據須要更改方法的內容。 因爲它是靜態方法，所以不能。 固然，若是咱們只須要在舊方法以前或以後添加功能，則能夠建立一個新類並在其中調用舊類-但這很麻煩。

界面問題

出於邏輯緣由，沒法經過接口定義靜態方法。 並且因爲沒法覆蓋靜態方法，所以當須要經過它們的接口傳遞靜態類時，靜態類是無用的。 這使咱們沒法將靜態類用做策略模式的一部分。 咱們能夠經過傳遞委託而不是接口來修補一些問題。

測試中

這基本上與上面提到的界面問題並存。 因爲咱們交換實現的能力很是有限，所以咱們也很難用測試代碼替換生產代碼。 一樣，咱們能夠將它們包裝起來，可是這將要求咱們更改代碼的大部份內容，以便可以接受包裝器而不是實際的對象。

福斯特斑點

因爲靜態方法一般用做實用程序方法，而實用程序方法一般具備不一樣的用途，所以咱們很快就會獲得一個充滿非一致性功能的大型類-理想狀況下，每一個類在系統中應具備一個單一的用途。 只要他們的目的獲得明肯定義，我寧願選擇五倍的課程。

參數蠕變

首先，這個可愛又天真的靜態方法可能只須要一個參數。 隨着功能的增加，添加了兩個新參數。 不久便添加了可選的其餘參數，所以咱們建立了該方法的重載（或僅添加默認值（使用支持它們的語言））。 不久，咱們有了一個採用10個參數的方法。 實際上只須要前三個，參數4-7是可選的。 可是，若是指定了參數6，則還必須填寫7-9。。。若是咱們建立一個類的惟一目的是執行此靜態方法所作的工做，則能夠經過在類中接受所需的參數來解決此問題。構造函數，並容許用戶經過屬性或方法設置可選值，以同時設置多個相互依賴的值。 一樣，若是方法變得如此複雜，那麼極可能不管如何它都必須屬於本身的類。

要求消費者平白無故地建立類的實例

最多見的論據之一是：爲何要求咱們的類的使用者建立一個實例來調用該單一方法，而以後卻再也不使用該實例？ 在大多數語言中，建立類的實例是很是便宜的操做，所以速度不是問題。 向消費者添加額外的代碼行是爲未來奠基更易於維護的解決方案奠基基礎的低成本。 最後，若是要避免建立實例，只需建立類的單例包裝便可，以方便重用-儘管這確實要求類是無狀態的。 若是不是無狀態的，您仍然能夠建立處理全部內容的靜態包裝器方法，而從長遠來看仍然能夠爲您帶來全部好處。 最後，您還能夠建立一個類來隱藏實例化，好像它是單例同樣：MyWrapper.Instance是一個僅返回new MyClass();的屬性new MyClass();

只有西斯（Sith）處理絕對

固然，我不喜歡靜態方法也有例外。 真正的實用程序類不會形成任何膨脹的風險，對於靜態方法來講就是個很好的例子-以System.Convert爲例。 若是您的項目是一次性的，對未來的維護沒有要求，那麼整體架構真的不是很重要-靜態仍是非靜態，都沒有關係-可是開發速度確實如此。

標準，標準，標準！

使用實例方法並不妨礙您也使用靜態方法，反之亦然。 只要差別化背後有其合理性並被標準化便可。 沒有什麼比查看遍及着不一樣實現方法的業務層更糟糕的了。

---

#5樓

我使用靜態類做爲定義給定類型的對象能夠在特定上下文中使用的「額外功能」的一種方式。 一般，它們原來是實用程序類。

除此以外，我認爲「將靜態類用做與特定對象無關的方法的組織單位」。 很好地描述它們的預期用途。