每當我編寫解決方案的東西，我傾向於使用大量的靜態類或根本沒有。例如，在最近的一個項目中，我不得不通過一些環節發送一個帶有一些字符串/布爾型/日期時間數據的類，並且唯一不是靜態的是這個數據控制類。其他一切（3個相當不同處理責任的龐大類）都是靜態的。何時去靜態類？
我想我所要求的這裏是當（爲什麼）我應避免使用靜態類爲這些「過程X，輸出Y」情況下，一些輸入。只要他們工作或者我是否在可伸縮性，插件支持等方面自我投入，可以始終使用它們嗎？
我希望這是一個好問題在這裏問。我並不是在爭論靜態類是否「更好」 - 只是在我應該避免使用靜態類時輸入。
仍兩個問題仍然有點相同。我對靜態類的主要關注是繼承和可訪問性。
當使用一個靜態類（大衆在最壞情況下），每個人都能夠訪問你的流程和功能。大部分時間不是你想要的。某些對象很容易進入你的功能並做一些修改。因此，依賴注入很好用。 （在參數中傳遞要修改的對象，在這種情況下爲process-object）。
爲了防止他人操縱你的process-object，爲什麼不嘗試使用某種單例模式（或者甚至是單獨模式），所以實際上有一個真正的對象可以與之交談？如果需要修改某些東西，可以將該對象傳遞給函數的參數。然後你可以讓一位經理持有你的process-object。其他人不應該去的對象。
靜態類也很難繼承。重寫靜態方法似乎有點奇怪。所以如果你確定這個過程不是唯一的過程，並且你會創建一些更具體的過程，那麼也應該避免靜態類。
靜態類通常用於小型數據容器和一般方法。除非需要，否則它不應包含大量數據。這些類是不可擴展的。
大部分的代碼我寫：
，所以我只是用對象幾乎一切。
我仍然使用靜態的東西，如：
我建議你有一個方法，靜若它只有一個方法。在這種情況下創建類的實例幾乎沒有意義
如果您希望字段的行爲有點像global variable，那麼您可以具有靜態屬性。這是一個設計模式匹配Singleton pattern
我使用靜態屬性來跟蹤需要由整個應用程序消耗的狀態。
對於與我的工作對象其餘一切去（有顯着輕微的例外）
廣泛利用靜就像是puting您的應用程序轉化爲具體的方式。除非非常特殊的情況，例如非常一般的效用/輔助方法，否則應該避免使用它們。 djeeg在上一個答案中發佈了一個不錯的列表。
我在使用靜態類時所看到的主要問題是，依賴關係是硬連線的。如果A類需要使用B類的特徵，它必須明確地知道它，這會導致緊耦合。
雖然這並不總是一個問題，但隨着代碼的增長，您可能會發現更改程序的行爲以適應新的要求更加困難。例如，如果你想使程序的行爲可配置，這將是困難的，因爲這將需要明確的if/switch代碼。否則，你可以簡單地使一個類依賴於接口和交換實現。
總之，您正在阻止自己使用衆所周知的設計模式，它們是已知的良好解決方案來解決您可能遇到的問題。
我通常會盡量避免在類中使用靜態方法。如果我需要全局訪問某些數據，我至少會在一個單例中包裝一個類。對於大型項目，我建議使用Inversion of Control容器以單例方式實例化並注入您的「全局」實例。
跳到我腦海的第一件事就是爲什麼你不能讓「數據控制類」負責對其數據進行任何必要的操作？這將避免需要一堆額外的靜態類，並減少不必要的耦合。 – 2011-01-12 10:43:19