C# 缺失的靜態導入：從 Java 學習語法糖與替代方案

緣起：跨語言視角的反思

從 C# 轉戰 Java 兩個月，最大的文化衝擊不是 GC 或框架，而是語法層面的「靜態導入」。Java 允許 import static com.util.Helper.*;，讓靜態方法像實例方法一樣直接呼叫，顯著提升測試碼與 DSL 風格程式的可讀性。

靜態導入的優勢：以測試碼為例

// 導入後直接使用 gotoPage、input、click、assertThat
@Test
public void should_say_hello_when_given_your_name() {
    gotoPage("hello");
    input("name", "yuyijq");
    click("sayButton");
    assertThat(helloPage.getLabel(), is("hello yuyijq"));
}

無類名前綴，程式碼讀起來像自然語言敘述業務流程，而非技術實作細節。這對 BDD 風格測試、流式 API 設計極具吸引力。

濫用的代價：語意資訊流失

但過度使用會模糊來源。例如大量導入 PortalOptions 列舉成員後：

map.get(MOST_VIEWED.toString());
map.get(LAST_VIEWED.toString());
// 讀者無法一眼看出這些常數屬於哪個領域

失去 PortalOptions.MOST_VIEWED 的上下文，維護者需跳轉定義才能確認語意，違背「程式碼給人看」的原則。

C# 的現狀與變通：擴展方法能否畫瓢？

C# 目前不支援靜態導入。嘗試用擴展方法模擬：

public static class UnitTestExtensions {
    public static T Mock<T>(this object o, Type mockType) {
        return (T)NMock.Mock(mockType);
    }
}

對 object 擴展雖能在所有類別直接呼叫 this.Mock<UserDAO>(...)，但污染全域命名空間，IntelliSense 噪音極大，屬反模式。

結論與建議

• C# 設計哲學傾向顯式優於隱式，靜態導入極難引入語言標準。
• 測試專案可考慮：
  ① 繼承基底測試類別集中常用靜態方法
  ② 使用 using static 別名（C# 6+ 僅支援單一類型，非命名空間）
  ③ 採用流式 API 設計（如 FluentAssertions）以方法鏈替代靜態導入
• Java 社區開源生態豐富，C# 開發者值得借鑑其 DSL 設計思維，而非單純羨慕語法糖。

語言特性的取捨反映了設計哲學差異。理解兩者權衡，才能在各自生態裡寫出地道、優雅的程式碼。