C# 分部方法深度解析：優缺點、適用場景與爭議觀點

什麼是分部方法？

分部方法是 C# 3.0 引入的一項語言特性，允許開發者在分部類別中聲明方法簽名，並在另一個分部類別檔案中提供實作。若未提供實作，編譯器會直接移除該方法及其所有呼叫點，不產生任何 IL 程式碼。這種「有則用、無則忽」的特性，使其成為輕量級擴展點的理想選擇。

核心限制與設計考量

分部方法受到嚴格限制：必須是 private、回傳 void、不允許 out 參數、不能是 virtual、extern 或委派目標。這些限制確保了當方法未被實作時，呼叫端的引數不會被評估，避免副作用。Visual Basic 同樣實作了相同語意的分部方法。

主要應用場景

1. 程式碼產生器的輕量級事件鉤子

如 LINQ to SQL 產生的實體類別，會在屬性設定前後插入 OnPropertyChanging、OnPropertyChanged 等分部方法。開發者可選擇性實作這些方法以加入驗證、同步更新等邏輯；若不實作，編譯器會完全移除呼叫，零效能損耗。

2. 自訂資料操作行為

DataContext 衍生類別中會產生 InsertEntity、UpdateEntity、DeleteEntity 等分部方法，供開發者覆寫預設的資料庫操作邏輯（如軟刪除、審計日誌）。

3. 條件式除錯輸出

利用 #if DEBUG 包裹分部方法實作，可在除錯建置中輸出追蹤資訊，釋出建置自動移除，避免到處散佈 #if 指令。

社群爭議與批判

雖然分部方法解決了程式碼產生場景的擴展問題，但也引發不少爭議：

• Alexander Jung 指出：私有限制導致無法透過中繼資料或動態方式掛接行為（如規則引擎、追蹤），破壞了層級分離。
• Stefan Wenig 擔心設計工具產生大量難以維護的程式碼，重蹈 COM 時代覆轍，呼籲回歸純程式碼開發。
• Ayende Rahien 更直言：「把程式碼設計工具埋葬吧，豎起分部方法的墓碑！」

總結

分部方法是為「程式碼產生與手寫程式碼共存」量身打造的妥協方案。在產生器框架（如 LINQ to SQL、EF Core 早期版本）中極具價值；但在一般應用開發中，傳統事件、介面或委派模式通常更具彈性與可測試性。使用時應權衡「零成本擴展點」與「侵入性限制」的得失。