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