在這個網站上有很多關於爲什麼應該避免單身人士的討論，但是有沒有任何情況下單身人士是有道理的並且是最好的選擇？是否有單身人士是最佳選擇的情況？
我認爲單身人士是最佳選擇的一個示例是，在實施Identity Map時，您需要跟蹤映射圖層中已從數據庫加載的所有模型。在這種情況下，地圖必須是有效的全局地圖，以便所有客戶端代碼使用地圖的同一個實例，並且它們都訪問相同的加載模型列表。最簡單的解決方案似乎是將該類實現爲單例（或靜態方法）。這是最好的方法還是有另一種方法？
有沒有其他的情況下，可以使用單身或他們總是壞？
請參閱this thread。
對於不允許靜態接口成員的語言（如.NET），單用戶（和類似用戶）有用。通過提供一個單例，你有一個實例可以提供接口作爲一個實例。因此，在.NET中，例子可能是：
Comparer<T>.Default - 提供了一個IComparer<T>實施分類TEqualityComparer<T>.Default - 提供了一個IEqualityComparer<T>實施散列/平等，測試T這是作爲一個指到一個端;這不是我們想要做的，只是一個合理的「如何」。
就「身份映射」示例而言，我個人寧願將它保留在實例上，並使實例可用於我的所有代碼。除此之外，如果您可以放棄測試之間的地圖，或者具有靈活性（稍後）同時具有多個標識地圖，則有助於可測試性。
想想您希望將應用程序中的不同事件記錄到單個文件的情況。在這種情況下，單例類Log會很有用。由於應用程序的不同部分將訪問Log類的相同實例。
單身人士確實有其用處。他們也有他們的濫用，有很多理由不喜歡他們或爲什麼他們使測試困難。
這是Singleton模式的一個小小的防守。
有時，程序需要表示或與真正單一的東西進行交互。一個例子是物理資源。例如，您不能有多個「標準輸出」。以及OS過程的表示（例如J2ME的Midlet）。
單身人士在使用類/接口來提供封裝和類似於裸體全局變量的好處是值得的。
當您使用網絡編程時，單身人士是有意義的：您通常只需要每個請求一個頁面輸出類的實例，以及一個用戶對象。數據庫是不同的 - 實現特權分離是想要多個數據庫對象的好理由。
我個人的指導方針是，如果你以後可以實例化一個類的一個對象，永遠不要將一個類硬編碼爲單例。這使得單例非常罕見，而且在應用程序代碼中通常是不必要的。在使用像Spring這樣的DI框架時尤其如此。
單身人士在框架中確實可以作爲'入口點'，但是規則是將它們用作'根單身人'（在依賴層次結構的開始處），讓其餘的代碼依賴於單身人士儘可能少。
單身人士確實有其用途。我將總結它們的用處如下：
「應該使用單例表示其對象，根據基本設計或要求，最多隻能有一個實例;並且存在與對象關聯的數據或資源這帶來了可衡量的成本。「這是我的意思。
1）你不應該在有很多東西的情況下使用Singleton，但我們只是碰巧對其中一個感興趣。如果系統中可能有兩個，明確地實例化一個。
2）Singleton的許多用途可以被一個包含所有靜態方法和數據的類所取代。如果你可以做到這一點沒有性能損失，那麼做。 3）如果設置對象有明顯成本，你應該考慮一個單例：例如，如果它是一個需要初始化的物理資源，或者它依賴於需要初始化的某個查找表。如果是這樣的話，在Singleton中，您可以推遲初始化成本，直到第一次使用該對象，而靜態類通常會在應用程序啓動時初始化。如果從未使用該對象，則永遠不支付初始化成本。
當你需要時，應該使用單身人士只有一個實例，並希望通過設計實施。它不應該使用，因爲它引起的全球副作用。
在你的情況，我認爲這是有道理的，因爲你想限制只有一個類的實例。
頁面輸出聽起來不像單身人士，如果它是每個請求... – 2009-01-16 09:49:32