Effective C# 原則 32：選擇小而內聚的組件

組件大小與內聚性的平衡

開發者常將所有類型塞進單一組件，這不利於重用與局部更新。合理的組件應「大小適中、包含少量公用型別」，並具備高內聚性：能用一句話描述其職責。例如 System.Collections 提供有序集合資料結構，System.Windows.Forms 提供 Windows 控制項模型。

避免極端

• 單一公用類別一個組件：失去 internal 型別封裝優勢，JIT 跨組件內聯效率較低。
• 單一巨大組件：部署彈性差、啟動載入慢、安全性檢查開銷大。

目標是建立「大小最合適」的組件：一個組件一個職責。

封裝與部署彈性

組件為相關類別提供二進位封裝。內部工具類別可共享實作細節而不對外公開。多組件架構簡化部署：例如三層架構中，伺服器端完整驗證邏輯，客戶端僅需子集，可將共用邏輯封裝為獨立組件供兩端參考，避免原始碼層面的重複編譯。

類似樂高積木的可替換性

若所有參數與回傳值皆為介面，相同介面的組件可輕易互換，系統其餘部分不受影響（參見原則 19）。

啟動效能考量

較小組件讓啟動時的 JIT 編譯與載入開銷可分期處理。大型組件需一次載入並為每個方法建立存根，增加啟動延遲。

實務建議：如何劃分組件

1. 觀察所有公用類別，以共同基類或介面歸類為一組件。
2. 加入支援這些類別功能的工具類別（標記為 internal）。
3. 將橫向存取的通用物件提煉為共用工具組件。

結果：每個組件僅包含必要的公用類別與內部支援類別，易於更新、重用，且最小化跨組件開銷。

大小是相對的

mscorlib.dll 約 2MB，System.Web.RegularExpressions.dll 僅 56KB，兩者皆符合「盡可能小」的原則。絕對大小取決於功能範圍：核心庫較大但廣泛使用，專用庫較小但功能聚焦。