C#筆記 - 自定義類型

類型成員總覽

一個自定義類型，最終就是把一組彼此有關聯的成員收斂到同一個邊界裡。以 C# 來說，最常見的成員包含：

如果把這批筆記串起來看，下面幾篇可以互相對照：

這篇不展開每一種成員的語法細節，而是先整理「型別本身」在設計時最容易忽略的幾個問題。

類型本身也有可見性。最常見的兩個層級是：

如果只是想把內部型別開給指定測試程序集，可以使用 InternalsVisibleTo：

[assembly: InternalsVisibleTo("MyFriendAssembly")]

這通常用在兩種情境：

不過一旦大量依賴 InternalsVisibleTo，通常也表示模組邊界可能還不夠穩定，這件事本身值得回頭檢查。

類型裡的成員還有更細的訪問層級：

實務上，一個簡單原則通常就夠用：

公開 API 一旦被依賴，後續版本就會被它綁住。

有些型別並不代表「要被建立出來的物件」，只是拿來收斂一組工具函式。這時候就適合用 static class：

public static class MathHelpers
{
    public static int Double(int value) => value * 2;
}

C# 對靜態類別有幾個直接限制：

這些限制的本質很單純：它不是物件模型，而是命名邊界。

從 IL 角度看，靜態類別其實是同時帶有 abstract 與 sealed 的類別。換句話說，CLR 並沒有「靜態類別」這個獨立分類，這是 C# 在語言層幫我們做的限制。

我們平常說的類型，實際上都存在某個程序集裡。程序集不只是部署單位，也是一個版本邊界。

這代表幾件事：

所以設計型別時，除了想「現在怎麼寫比較方便」，也要多想一步：這個成員是不是值得成為長期契約。

方法呼叫在 IL 裡常見兩種指令：

可以先這樣理解：

雖然 callvirt 名字看起來像只用於虛方法，但 C# 編譯器有時連一般實例方法也會產生 callvirt，因為它還順便提供了空參考檢查的效果。

如果是 base.Method() 這種語法，編譯器表達的是「呼叫基底版本」，那麼就不會再經過一般的虛擬分派路徑。

自定義類型真正難的地方，通常不是語法，而是邊界：

這些判斷會直接影響可維護性，甚至比單一語法點更重要。