C# 靜態方法使用經驗與最佳實踐淺談

靜態方法優缺點快速回顧

何時使用靜態方法 (✅ 推薦場景)

1. 純函式/工具方法：Math.Sin, String.IsNullOrEmpty, Path.Combine — 無副作用、無狀態、輸入完全決定輸出。
2. 擴充方法：public static string ToMd5(this string s) — 必須為靜態類別中的靜態方法。
3. 工廠/建構者模式：User.Create(...), DbContextOptionsBuilder — 封裝複雜建構邏輯。
4. 單例存取點：Logger.Instance, ConfigurationManager.AppSettings (舊版)。
5. 效能關鍵熱路徑：經剖析確認實例化開銷為瓶頸時 (極少見)。

何時避免靜態方法 (❌ 反模式)

1. 業務邏輯含狀態：static decimal CalculateOrderTotal(Order o) 若內部存取靜態快取/設定 → 測試需重置全域狀態、平行測試互相干擾。
2. 資料存取/外部依賴：static User GetUser(int id) 直接呼叫 ADO.NET/EF Core → 無法替換為 Mock/InMemory 單元測試。
3. 需支援多種實作：付款處理、日誌記錄、快取策略 → 應定義介面 + 依賴注入。
4. ASP.NET Core 等現代框架中：內建 DI 容器，服務應註冊為 Scoped/Transient/Singleton，而非靜態類別。

重構範例：從靜態到可測試

// ❌ 靜態版本 - 難以測試
public static class OrderService
{
    public static decimal CalculateTotal(int orderId)
    {
        var repo = new SqlOrderRepository(); // 硬編碼依賴
        var order = repo.Get(orderId);
        return order.Items.Sum(i => i.Price * i.Qty);
    }
}

// ✅ 介面 + 實例版本 - 可注入、可測試
public interface IOrderRepository { Order Get(int id); }
public class SqlOrderRepository : IOrderRepository { ... }
public class OrderService
{
    private readonly IOrderRepository _repo;
    public OrderService(IOrderRepository repo) => _repo = repo;
    public decimal CalculateTotal(int orderId) 
        => _repo.Get(orderId).Items.Sum(i => i.Price * i.Qty);
}

// 單元測試
var mock = new Mock();
mock.Setup(r => r.Get(1)).Returns(new Order { Items = new[] { new Item { Price=10, Qty=2 } } });
var svc = new OrderService(mock.Object);
Assert.Equal(20, svc.CalculateTotal(1));

現代 .NET 最佳實踐總結

• 預設使用實例方法 + 依賴注入 (ASP.NET Core / .NET 6+ 內建 DI)。
• 靜態方法僅限純工具、擴充方法、工廠、單例存取點。
• 避免靜態可變狀態 (static 欄位/屬性)，若必須使用請加 readonly、ConcurrentDictionary、Lazy<T> 並仔細處理執行緒安全。
• 單元測試優先思維：寫程式碼時問自己「如何 Mock 這個依賴？」 → 自然導向介面 + 實例設計。

靜態方法本身非善非惡，**關鍵在於是否引入隱性共享狀態與硬編碼依賴**。守住「無狀態、無副作用、可純函式化」底線，即能安全享受其便利性。