討論C#分部方法
C#新增的特性中引起爭議的有許多，分部方法（Partial Method）算是一個。分部方法通常被定義在一個分部類中，在常規的類文件中也可實現。如果分部方法沒有被實現，編譯器就不會對他們進行編譯。
分部方法有著嚴格的限制。它們必須是私有的，不能返回值，不能有輸出參數。因為任何針對沒有被實現的分部方法的調用都會簡單地被忽略，所以說這些限制是非常有必要的。反過又意味著，分部方法不能作為一個明確分配的變量。Visual Basic也有分部方法，盡管VB不需要對變量的明確分配，它也有同樣的限制。
有那么多的限制，有人可能會問，“它們有什么優點？”。這個問題問得好，基本上，C#分部方法僅被代碼生成器在處理輕量級事件的時候使用。就像 Alexander Jung所解釋的 ：
分部方法通常（也可能是***相關的）的應用場景就是在代碼生成的時候用于處理輕量級事件。假設你解析一個數據庫或者一個XML文件，然后生成了數據類，結果你會發現有數十個類、幾百個屬性以及一大堆泛型和模板文件等。分部方法另外一個經常被用到的地方是驗證，或者讓屬性的setter去更新另一個屬性。所以如果你要使用產生的代碼，或者在運行時有幾百個事件和數千個方法調用的話（ 其實大多數情況下只用到了其中的一點點），就讓分部方法來吧。分部方法在聲明和使用時要比事件容易得多，如果沒有用到它們，它們就會消失。
性能的提升并不是沒有代價的。從分部方法必須是私有的限制中，Alexander發現了它們的不足之處：
缺點：如果你喜歡元數據驅動的應用，并且已經被ASP.NET的數據綁定所困擾時（因為沒有其他的方法可以附上元數據）……那么，就準備著在將來丟失信息吧。如果你需要為屬性的setter增加一些事件（基于跟蹤和調試的需要），如果你需要某個動態的行為（比如附上某個通用規則引擎）等等，那么就讓我們祈禱代碼分析器的開發人員能夠預知這個場景（或者已經做好了準備）吧。你有了一個清晰的層的分離，那么實體就應該對UI一無所知嗎？是的，將代碼直接放到數據類中會破壞層的關系，但是你可以手動地用分部方法實現真正的事件啊。
另外一些人對于C#分部方法也是憂慮重重，大部分是關于代碼設計器的使用的。Stefan Wenig寫道：
首先，我不是非常熱衷于設計器。我憂慮的是設計器也許很快就會將我們送上過去基于COM開發時的老路，數百個設計器和向導產生了那么多沒人想去看的ATL和MCF代碼。在我們陷于設計器、創建的無用文件和復雜的構建過程時，使用Ruby的家伙們在笑，因為他們用幾行代碼就可以解決（聯想一下上世紀90年代COM/C++和Java的比較）。難道對于基于代碼的開發人員生產率不是C#所首要考慮的（看看VB的設計器驅動的RAD路線圖）？我們不應該再沉浸于基于設計器的，企業類庫思想的，樂于使用軟件工廠代碼設計器的幻想中了。團結起來，抵制它們！
Ayende Rahien也沒有嘴軟：
讓我們一起埋葬這些代碼設計器吧，豎起C#分部方法的輝煌墓碑！
【編輯推薦】
