??? 最近大家都在討論這篇文章 C與C++社區(qū)混戰(zhàn)，C#會重蹈覆轍嗎？ ，閑著無聊也讀了一下，發(fā)現(xiàn)果然還是太不能接受firelong的觀點。

??? 按照firelong的觀點，刪除C#以下功能： 委托和事件，反射，特性，屬性、索引器、析構(gòu)器，JIT編譯，泛型，Linq，dynamic。

??? 也許這些在firelong看來都是些爛特性，但是在不同的人眼中這些都是有非常重要的用途的特性。別的功能點先不說，我這里就說反射，特性和dynamic這三個

反射和特性

??? 反射不是c#本身的語言特性，是類庫提供的功能。

??? firelong說反射的用處很小，也許對大多數(shù)人來說是這樣，但是如果寫的是框架程序（插件框架、單元測試框架、WebService框架、WCF框架以及更多的框架），那離開反射基本就沒法寫了。

??? 然后說說特性，當(dāng)然這個依賴于反射，如果沒有反射，特性就沒用了。

??? 個人認為特性是.net最重要的特點之一，離開它，估計全球的.net程序員都要多寫一倍的代碼。這絕對不是空穴來風(fēng)，特性的最大特點是提供了契約式的代碼編成方式。

??? 想想ms實現(xiàn)了Xml序列化，從此只要標(biāo)記上幾個特性，對象和xml之間就有了一座橋，可以任意轉(zhuǎn)換。需要做的僅僅是告訴xml序列化器用什么樣的方式去序列化。如果按照firelong說的用接口，好吧有個現(xiàn)成的接口IXmlSerializable，事實上根本沒幾個人會用這個接口來自己定制序列化，其次，為了實現(xiàn)這個接口所消耗的代碼量將非常多，然后還要為這些代碼做測試，發(fā)現(xiàn)并處理bug，一路上帶來的成本開銷將是非常驚人的。

??? 除了Xml序列化的優(yōu)勢，可以再想想WCF/WebService，不用特性和反射的話，就只能自己去偵聽端口，分析request的內(nèi)容，抓取其中的數(shù)據(jù)，在做各類運算/處理，將返回信息打包成一個response，再發(fā)送。這些多出來的工作量誰來承擔(dān)？

?? 再說說單元測試，NUnit的反射+特性方式要是改成純接口實現(xiàn)的版本？大家愿意用哪個？

dynamic

??? 最后說說dynamic，firelong說“去掉，真想dynamic，讓ruby、python, f#等去做吧”，首先dynamic和f#沒關(guān)系，f#也是靜態(tài)類型，如果真的需要動態(tài)語言的部分，確實推薦使用ruby、python等原生的動態(tài)語言，恰恰因為這個c#才要dynamic。

??? 很有趣的是firelong認識到和其他語言的互操作（類似P/Invoke）的重要性，怎么卻沒認識到dynamic也是這個互操作的一部分。

??? c#如何與這些動態(tài)語言互操作？在4.0里面當(dāng)然是直接用dynamic，剩下的部分不需要關(guān)心，只要動態(tài)語言是建立在DLR之上的，就一定可以在c#中用dynamic來訪問他們的成員。

??? 所以firelong提出不要dynamic，確實讓我很詫異，想想原因，可能和很多人誤用了dynamic有關(guān)，但是請別忘了dynamic的本職工作，不是為了方便反射，而是為了和動態(tài)語言的互操作。

小結(jié)

??? c#不是為某一個人而創(chuàng)建的，所以，那些對你沒用的東西，對別人未必沒用。當(dāng)然，如果覺得對你確實沒用，完全可以不用，ms有沒說不用xx特性就不讓你編譯失敗。

??? 但是，不要因為你覺得沒用，就要求刪除這些功能。想想一個C程序員對你說，“面向?qū)ο笥惺裁从?#xff0c;全部用函數(shù)不就做出來了”，你會真的把面向?qū)ο蟮牟糠秩サ魡?#xff1f;

轉(zhuǎn)載于:https://www.cnblogs.com/vwxyzh/archive/2010/06/22/1762450.html

總結(jié)

以上是生活随笔為你收集整理的己所不欲，勿施于人的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。