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