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