為什麼單例模式被視為「邪惡」的反模式？

引言

單例模式確保一個類只有一個實例，並提供全域存取點。雖然看似方便，但資深架構師 Scott Densmore（翻譯自 Brian Button 觀點）指出：單例模式本質上是披著設計模式外衣的全域變數，會嚴重破壞軟體設計的核心原則。以下是四大核心罪狀：

罪狀一：偽裝的全域狀態，隱藏依賴關係

單例提供全域存取點，讓你不必傳遞參考。但這與全域變數無異：

• 類別間的依賴關係**隱藏在實作細節中**，無法從介面簽名看出。
• 維護者必須閱讀原始碼才能發現類別實際依賴了哪些服務。
• 這是「設計氣味」：為了避免傳遞參數而引入全域狀態，實則是設計不良的徵兆。

罪狀二：違反單一職責原則 (SRP)

單例類別同時承擔兩個職責：

1. 核心業務邏輯
2. 控制自身實例化數量（生命週期管理）

正確做法：將建立與存取控制移至工廠或建構器，讓業務類別專注於業務。

罪狀三：導致緊耦合，扼殺可測試性

• 程式碼直接依賴具體的單例類別（Singleton::getInstance()），無法透過多型替換為 Mock/Stub。
• 單元測試要求鬆耦合，以便隔離測試目標。單例將具體實現硬編碼在呼叫端，使得隔離極其困難。
• 替代方案：依賴注入 (DI)，透過建構子或設值器傳入依賴，輕鬆替換測試替身。

罪狀四：持久狀態污染測試隔離性

• 單例實例儲存在靜態欄位，生命週期貫穿整個程式執行期間。
• 單元測試之間**狀態會相互滲透**；測試順序不同可能導致結果不同（假陽性/陰性）。
• 靜態狀態是單元測試的大敵；單例天生依賴靜態儲存，難以在測試間重置。

更好的替代方案總結

結語

單例模式並非絕對不可用，但在現代 PHP 應用（特別是採用 DI 容器的框架如 Laravel、Symfony）中，**幾乎總有更優雅、可測試、可維護的替代方案**。下次想寫 private static $instance 時，請三思：是否真的是設計需要，還是只是圖省事？