.NET 遺忘錄（八）：dynamic 濫用與特性誤區的深度反思

C# 4.0 引入 dynamic 關鍵字，本意是簡化 COM 互操作、動態語言互通與匿名型別跨方法傳遞。然而現實中，大量開發者將其視為「萬能鑰匙」，導致效能損耗、智能感知失效、執行時錯誤延遲暴露等嚴重後果。

dynamic vs var：編譯時與執行時的分水嶺

dynamic 正確使用場景

1. COM 互操作：替代冗長的 reflection 呼叫 Excel/Word/舊版 ActiveX
2. 動態語言互通：IronPython/IronRuby 物件交互
3. 匿名型別跨層傳遞：LINQ 查詢結果跨方法邊界時，dynamic 可避免定義 DTO（但建議改用 Tuple/Record）

擴展方法濫用：模組化的隱形殺手

擴展方法本質是「靜態方法的語法糖」，只適用於三種情境：

• 獨立開發的組件需擴充第三方/框架類別且無法修改原始碼
• 團隊共享的封裝組件缺少特定方法，重構成本過高
• 擴充 .NET Framework 基礎類別（如 string, IEnumerable）

若在專案內部大量定義擴展方法，會造成「方法汙染」：IntelliSense 列表膨脹、命名衝突風險、語意歸屬模糊。請嚴格限制在 Extensions 命名空間與專用靜態類別中。

泛型誤區：List<object> 是反模式

泛型優勢在於型別安全與避免裝箱/拆箱。濫用表現：

• List<object>：完全喪失型別檢查，不如用 ArrayList 誠實
• 方法內部泛型參數為參考型別且無型別約束：單態化生成碼膨脹，效能無增益
• 過度巢狀泛型（Dictionary<string, List<Tuple<int, Func<T>>>>）：編譯緩慢、除錯困難

結語：知其然更要知其所以然

每個語言特性都有其設計初衷與適用邊界。盲目跟風使用新特性，本質上是「知其然不知其所以然」。珍愛程式碼品質，遠離盲目跟風——這才是資深工程師的底色。