Effective C# 原則 32：打造小而內聚的組件，提升重用與部署彈性

避免「萬用組件」反模式

常見錯誤：將所有功能塞進單一組件（除廚房水槽外的一切）。這嚴重阻礙重用與局部更新。小而內聚的組件才是正道。

內聚性：一句話說清職責

• System.Collections：提供有序集合資料結構。
• System.Windows.Forms：Windows 控制項模型。
• Web Form 與 Win Form 分屬不同組件，因彼此無關。

你的組件也應能用一句簡單話語描述職責。MyApplication.dll 提供一切？太懶惰，也難以重用。

組件大小的折衷藝術

• 過小：失去 internal 存取層級優勢（組件內可見、外部不可見），JIT 內聯最佳化跨組件失效，安全性檢查增加開銷。
• 過大：載入啟動慢、JIT 編譯多、版本管理難、重用困難。

目標：單一職責的相關類型群。相關類別放同一組件，享受 internal 封裝與 JIT 最佳化；無關功能拆分離。

部署彈性：組件如樂高積木

三層架構範例：客戶端與伺服器共用驗證邏輯。將嚴格伺服器驗證拆出核心子集部署至客戶端，共享二進位組件，優於原始碼重用重編。更新時僅替換對應組件，降低風險。

實務建議：從公開類別著手劃分

1. 以共同基底類別/介面歸類公開類別。
2. 加入支援其功能的工具類別（設為 internal）。
3. 將公開介面獨立為單一組件。
4. 橫向通用物件（如加密、日誌）歸入共用工具組件庫。

結果：職責單一、易重用、易更新、最小化跨組件開銷。