程序開發(fā)目前主流開發(fā)技術(shù)的分析和總結(jié).docx

程序開發(fā):目前主流開發(fā)技術(shù)的分析和總結(jié)主流的程序設計語言：C+、Delphi(ObjectPascal)、Java、C#桌面應用程序框架：MFC、VCL、QT、JavaAWTSWING、.Net企業(yè)應用程序框架：WindowsDNA（ASP、COM、COM+）、J2EE、.NetFramework開發(fā)工具：VisualBasic、Delphi、VisualC+、C+Builder、VisualC#*程序設計語言：C+Delphi（本來應該是ObjectPascal，但為了簡單，我就語言和工具混為一談吧）JavaC#(雖然他剛剛推出，但因為微軟為之傾注了大量心血，一定會成為一種重要的開發(fā)語言)*桌面應用程序框架:MFCVCL*企業(yè)應用程序框架:WindowsDNAJ2EE.Net*COM技術(shù)：我單獨提出這項技術(shù)，是因為它無法簡單的被視為語言、桌面應用程序框架或企業(yè)應用程序框架，它與這些都有關(guān)系。2.1 程序設計語言2.1.1 C+語言的演進最初要從二進制代碼和匯編說起，但那太遙遠了。我們就從面向過程的語言說起吧（包括BasicCFortranPascal）。這種面向過程的高級語言終于把計算機帶入了尋常的應用領(lǐng)域。其中的C語言因為它的簡單和靈活造就了Unix和Windows這樣的偉大的軟件。面向?qū)ο蟮恼Z言是計算機語言的一個合乎邏輯的進化，因為在沒有過多的影響效率、簡單性的前提下提供了一種更好的組織數(shù)據(jù)的方法，可使程序更容易理解，更容易管理這一點可能會引出不同意見，但事實勝于雄辯，C+終于讓C語言的領(lǐng)地越來越小，當今還活著的計算機語言或多或少的都具備面向?qū)ο蟮奶卣?，所以這一點并不會引起太多困惑。C+的成功很大程度要歸因于C，C+成為它今天的樣子是合乎邏輯的產(chǎn)物。因為在面向過程的時代，C幾乎已經(jīng)統(tǒng)一天下了。今天著名的語言象JavaC#都從C借鑒了很多東西，C#本來的意思就是C+。其實C+曾經(jīng)很有理由統(tǒng)一面向?qū)ο蟪绦蛟O計語言的天下來著，但可惜的是，C+太復雜了。即使是一個熟練的程序員，要你很清楚的解釋一些問題你也會很頭痛。舉幾個還不是那么復雜的例子來說：對=的重載成員轉(zhuǎn)換函數(shù)拷貝構(gòu)造函數(shù)轉(zhuǎn)化構(gòu)造函數(shù)之間有什么區(qū)別和聯(lián)系呢？定義一個類成員函數(shù)private:virtualvoidMemFun()=0;是什么意義呢？int(*(*x(int)4)(double);是什么意思？還有其他的特征，比如說可以用來制造一種新語言的typedef和宏（雖然宏不是C+的一部分，但它與C+的關(guān)系實在太密切了），讓你一不小心就摔跤的內(nèi)存問題（只要new和delete就可以了嗎？有沒有考慮一個對象存放在容器中的情況？）諸如此類，C+是如此的復雜以至于要學會它就需要很長的時間，而且你會發(fā)現(xiàn)即使你用C+已經(jīng)好幾年了，你還會發(fā)現(xiàn)經(jīng)常有新東西可學。你想解決一個應用領(lǐng)域的問題比如說從數(shù)據(jù)庫里面查詢數(shù)據(jù)、更改數(shù)據(jù)那樣的問題，可是你卻需要首先為C+頭痛一陣子才可以，是的，你精通C+，你可以很容易的回答我的問題，可是你有沒有想過你付出了多大的代價呢？我不是想過分的譴責C+，我本人喜歡C+，我甚至建議一個認真的開發(fā)普通的應用系統(tǒng)的程序員也去學習一下C+，C+中的一些特性，比如說指針運算模板STL幾乎讓人愛不釋手，宏可以用幾個字符代替很多代碼，對系統(tǒng)級的程序員來說，C+的地位是不可替代的，Java的虛擬機就是C+寫的。C+還將繼續(xù)存在而且有旺盛的生命力。2.1.2 Java和C#Java和C#相對于C+的不同最大的有兩點：第一點是他們運行在一個虛擬環(huán)境之中，第二點是語法簡單。對于開發(fā)人員而言，在語法和語言機制的角度可以把Java和C#視為同一種語言。C#更多的是個政治的產(chǎn)物而不是技術(shù)產(chǎn)物。如果不是Sun為難微軟的話，我想微軟不會費盡心力推出一個和Java差不多的C+，記得Visual J+嗎，記得WFC嗎？看看那些東西就會知道微軟為Java曾經(jīng)傾注了多少心血。而且從更廣泛的角度來說，兩者也是非常相似的C#和Java面對的是同樣的問題，面向應用領(lǐng)域的問題：事務處理、遠程訪問、Webservice、Web頁面發(fā)布、圖形界面。那么在這一段中，我暫且用Java這個名字指代Java和C#兩種語言盡管兩者在細節(jié)上確實有區(qū)別。Java是適合解決應用領(lǐng)域的問題的語言。最大的原因Java對于使用者來說非常簡單。想想你學會并且能夠使用Java需要多長時間，學會并且能夠使用C+要多長時間。由于Java很大程度上屏蔽了內(nèi)存管理問題，而且沒有那么多為了微小的性能提升定義的特殊的內(nèi)容（比如說，在Java里面沒有virtual這個關(guān)鍵字,Java也不允許你直接在棧上創(chuàng)建對象，Java明確的區(qū)分bool和整型變量），他讓你盡量一致的方式操作所有的東西，除了基本數(shù)據(jù)類型，所有的東西都是對象，你必須通過引用來操作他們；除了這些之外，Java還提供了豐富的類庫幫助你解決應用問題因為它是面向應用的語言，它為你提供了多線程標準、JDBC標準、GUI標準，而這些標準在C+中是不存在的，因為C+并不是直接面向解決應用問題的用戶，有人試圖在C+中加入這些內(nèi)容，但并不成功，因為C+本身太復雜了，用這種復雜的語言來實現(xiàn)這種復雜的應用程序框架本身就是一件艱難的事情，稍后我們會提到這種嘗試COM技術(shù)。漸漸的，人們不會再用C+開發(fā)應用領(lǐng)域的軟件，象MFCQTCOM這一類的東西最終也將退出歷史舞臺。2.1.3 DelphiDelphi是從用C+開發(fā)應用系統(tǒng)轉(zhuǎn)向用Java開發(fā)應用系統(tǒng)的一個中間產(chǎn)物。它比C+簡單，簡單的幾乎象Java一樣，因為它的簡單，定義和使用豐富的類庫成為可能，而且Delphi也這么做了，結(jié)果就是VCL和其他的組件庫。而另一方面，它又比運行于虛擬環(huán)境的Java效率要高一些，這樣在簡單性和效率的平衡之中，Delphi找到了自己的生存空間。而且預計在未來的一段時間之內(nèi)，這個生存空間將仍然是存在的?？梢悦黠@的看出，微軟放棄了這個領(lǐng)域，他專注于兩方面：系統(tǒng)語言C+和未來的Java(其實是.Net)。也許這對于Borland來說，是一件很幸運的事情。如果我能夠給Borland提一些建議的話，那就是不要把Delphi弄得越來越復雜，如果那樣，就是把自己的用戶趕到了C+或Java的領(lǐng)地。在虛擬機沒有最終占領(lǐng)所有的應用程序開發(fā)領(lǐng)域之前，Delphi和Delphi的用戶仍然會生存得很好。2.2桌面應用程序框架目前真正成功的桌面應用程序框架只有兩個，一個是MFC，一個是VCL，還有一些其他的，但事實上并未進入應用領(lǐng)域。遺憾的是我對兩個桌面應用程序框架都不精通。但這不妨礙我對他做出正確的評價。2.2.1MFCMFC（還有曾經(jīng)的OWL）是SDK編程的正常演化的結(jié)果，就象是C+是C的演化結(jié)果一樣。MFC本身是一件了不起但不那么成功的作品，而且它過時了。這就是我的結(jié)論。MFC凝聚了很多天才的智慧當然，OWL和VCL也一樣，侯捷的深入淺出MFC把這些智慧擺在了我們的面前。但是這件東西用起來估計不會有人覺得很舒服，如果你一直在用Java、VB或者Delphi，再回過頭來用MFC，不舒服的感覺會更加強烈。我不能夠解釋MFC為什么沒有能夠最終發(fā)展成和VCL一樣簡單好用的桌面程序框架，也許是微軟沒精力或者沒動力，總之MFC就是那個樣子了，而且也不會再有發(fā)展，它已經(jīng)被拋棄了。我有時候想，也許基于C+這種復雜的語言開發(fā)MFC這樣的東西本身就是錯誤的可以開發(fā)這樣的一個框架，但不應當要求使用它的人熟悉了整個框架之后才能夠使用這個系統(tǒng)，但很顯然，如果你不了解MFC的內(nèi)部機制，是不太可能把它用好的，我不能解釋清楚為什么會出現(xiàn)這種現(xiàn)象。2.2.2VCL相比之下VCL要成功的得多。我相信很多使用VCL的人可能沒有像MFC的用戶研究MFC那樣費勁的研究過VCL的內(nèi)部機制。但這不妨礙他們開發(fā)出好用好看的應用程序，這就足夠了，還有什么好說的呢？VCL給你提供了一種簡單一致的機制，讓你可以寫出復雜的應用程序。在李維的Borland故事那篇文章中曾經(jīng)說過，在Borland C+ 3.1推出之后Borland就有人提出開發(fā)類似C+ Builder一類的軟件，后來竟未成行。是啊，如果C+ Builder是在那個時候出現(xiàn)的，今天的軟件開發(fā)領(lǐng)域?qū)窃趺礃拥氖澜缒?？真的不能想象。也許再過一段時間，這些都將不再重要。因為新生的語言如Java和C#都提供了類似于VCL的桌面應用程序框架。那個時候，加上Java和C#本身的簡單性，如果他們的速度有足夠塊，連Delphi這種語言也要消失了，還有什么好爭論的呢？只是對于今天的桌面程序開發(fā)人員來說，VCL確實是最好的選擇。2.3 企業(yè)應用程序框架2.3.1 Windows DNAWindows DNA的起源無從探究了。隨著.Net的推出，事實上Windows DNA將成為歷史的陳跡。Windows DNA雖然是幾乎所有的企業(yè)應用程序開發(fā)人員都知道的一個名詞，但我相信Windows DNA事實上應用的最廣泛的是ASP而不是COM+。真正的COM開發(fā)有多少人真正的掌握了呢，更不要提COM+(我有必要解釋一下：COM+是COM的執(zhí)行環(huán)境，它提供了一系列如事務處理、安全等基礎服務，讓應用程序開發(fā)人員盡量少在基礎架構(gòu)設計上花精力)當然我這里指的COM開發(fā)不是指VB下的COM開發(fā)，所以要這么說，是因為我覺得如果不能理解用C+進行COM開發(fā)，也就不能真正的理解COM技術(shù)。如果以一種技術(shù)沒有被廣泛理解和應用作為失敗的標志，那么Windows DNA實際上是失敗了，但這不是它本身的錯，而是基于C+的COM技術(shù)的失敗造成的。多層應用、系統(tǒng)開發(fā)角色分離的概念依然沒有過時。2.3.2 J2EEJ2EE是第一套成功的企業(yè)應用程序開發(fā)框架。因為它把事務處理、遠程訪問、安全這些概念帶入了尋常百姓家。這種成功我認為要歸因于Java的簡單性。Java的簡單，對于J2EE容器供應商來說一樣重要。開發(fā)一個基于Java的應用服務器要比基于C+的更容易。而且由于Java的簡單性，應用系統(tǒng)開發(fā)者出錯的機會也會少一些，不會像C+的開發(fā)者那樣受到那么多挫折。開發(fā)基于Java的企業(yè)應用系統(tǒng)的周期會更短，這恐怕是不容爭辯的事實。不論如何，是J2EE讓事務處理、遠程訪問、安全這些原來幾乎都是用在金融系統(tǒng)中的概念也被一般的企業(yè)用戶使用并從中獲得利益。2.3.3 .NET.Net有什么好說的呢？其實，它不過是微軟的J2EE。事務處理、安全、遠程訪問，這些概念在.Net中都找得到。更有力的說明是，微軟也利用了.Net實現(xiàn)了一個PetStore。所以，.Net與J2EE幾乎是可以完全對等的。但微軟確實是一家值得尊敬的公司我指從技術(shù)上，象Web form這種東西，我相信很多Web應用開發(fā)者都夢想過甚至自己實現(xiàn)過，但Sun卻一直無動于衷，而且似乎Borland也沒有為此作過太多努力，好像有過類似的東西，但肯定是不怎么成功Borland已經(jīng)很讓人敬佩了，我們也許無法要求太多。2.4 COM技術(shù)COM應當是個更廣泛的詞匯，其實我覺得Axtive X、OLE、Auto mation、COM+都應當提及，因為如果你不理解COM，上面的東西你是無法理解的。而且，我只是想說明COM是一種即將消亡的技術(shù)，僅僅說說COM的復雜性和他的問題就夠了，所以不會提及那些東西。為什么會出現(xiàn)COM技術(shù)？COM的根本目標是實現(xiàn)代碼的對象化的二進制重用，進而實現(xiàn)軟件的組件化、軟件開發(fā)工作的分工。這要求他做到兩點：第一，能夠跨越不同的語言，第二，要跨越同一種語言的不同編譯器。COM技術(shù)為這個目標付出了沉重的代價，尤其是為了跨越不同的編譯器，以至于無論對于使用者而言還是開發(fā)者而言，他都是一個痛苦的技術(shù)。但幸運的事，這一切終歸要結(jié)束了。讓我們從這個目的出發(fā)看看COM為什么會成為它現(xiàn)在的樣子。其實COM不是什么新玩意，最初的DLL就是重用二進制代碼的技術(shù)。DLL在C的年代可能還不錯，但到了C+的年代就不行了。原因在于如果你在.h文件中改變了類定義（增加或者減少了成員變量），代碼庫用戶的代碼必須重新編譯才可以，否則用戶的代碼會按你的舊類的結(jié)構(gòu)為你的新類分配內(nèi)存，這將產(chǎn)生什么后果可想而知。這就是為什么通過接口繼承和通過接口操作對象成為COM的強制規(guī)范的原因，能夠通過對象的方式組織代碼是COM的重要努力。那么著名的IUnknown接口又是怎么回事呢？這是為了讓使用不同編譯器的C+開發(fā)人員能夠共享勞動成果。首先看QueryInterface，因為COM是基于接口的，那么一個類可能實現(xiàn)了幾個接口，而對于用戶來說，你又只能通過操作接口來操作類，這樣你必須把類造型成某個特定的接口，使用Dynamic_cast嗎？不行，因為這是編譯器相關(guān)的，那么，就只好把它放在類的實現(xiàn)代碼中了，這就是QueryInterface的由來。至于AddRef和Release，他們產(chǎn)生的第一個原因是delete這個操作要求一個類具有虛析構(gòu)函數(shù)（否則的話，他的父類的析構(gòu)函數(shù)將不會被調(diào)用），但不幸的是不同的編譯器中析構(gòu)函數(shù)在vtbl中的位置并不相同，這就是說你不能讓用戶直接調(diào)用delete，那么你的COM對象必須提供自己刪除自己的方法；另外的原因在于一個COM對象可能作為幾個接口在被用戶同時使用，如果用戶粗暴的刪掉了某個接口，那么其他的接口也就不能用了，這樣，只好要求用戶在想用一個接口的時候通過AddRef通知COM對象“我要使用你了，你多了一個用戶”，而在不用之后要調(diào)用Release告訴COM對象“我不用你了，你少了一個用戶”，如果COM對象發(fā)現(xiàn)自己沒有用戶了，它就把自己刪掉。再看看詭異的HRESULT，這是跨語言和跨編譯器的代價。其實，異常處理是物競天擇的結(jié)果連一直用效率作標榜的C+都肯犧牲效率來實現(xiàn)這個try-catch，可見它的意義，但COM為了照顧那些低級的語言居然拋棄了這個特征產(chǎn)生的結(jié)果就是HRESULT。我們可以看看他是多么愚蠢的東西。首先，我們要通過一個整數(shù)來傳遞錯誤信息，通過IErrorInfo來查找真正的錯誤描述，本來在現(xiàn)代語言中一個try-catch可以解決的問題，現(xiàn)在我們卻需要讓用戶和開發(fā)者都走很多路才能解決，你怎么評價這個結(jié)果？其次，由于這個返回計算結(jié)果的位置被占用了，我們不得不用怪異的out參數(shù)來返回結(jié)果。想想一個簡單的int add(intop1,intop2)在COM中竟然要變成HRESULT add(intop1,intop2,int* result)，我不知道你對此作何感想。而且由于COM的方法無法返回一個對象而只能返回一個指針，為了完成一個簡單的std:string GetName()這一類的操作，你要費多少周折你需要先分配一塊內(nèi)存空間，然后在COM實現(xiàn)中把一個字符串拷貝到這個空間，用完了你要刪掉這個空間，不知道你是否覺得這種工作很幸福，反正我覺得很痛苦。還有COM為了照顧那些解釋性的語言，又加入了Automation技術(shù)，你有沒有為此覺得痛苦？本來一個簡單的方法調(diào)用，現(xiàn)在卻需要傳給你一個標志變量，然后讓你根據(jù)這個標志變量去執(zhí)行相應的操作。（這一點我現(xiàn)在仍然不明白，為什么解釋性的語言需要通過這個方式來執(zhí)行一個方法）?！拔沂軌蛄?，我覺得頭痛”，你會說，是啊，我想所有的人都受夠了，所有這些因素實際上是把COM技術(shù)變成了一頭讓人無法駕馭的怪獸。人對復雜事物的掌控能力終究是有限的，C+本身已經(jīng)夠復雜了，COM的復雜性已經(jīng)超出了我們大部分人的控制能力，你需要忍受種種痛苦得到的東西與你付出的代價相比是不是太不值得了？我們學習是為了解決問題，而現(xiàn)在我們卻需要為了學習這件事情本身耗費太多的精力。這些痛苦的東西太多了，我在這里說到的，其實只是一小部分而已。計算機技術(shù)是為人類服務的，而不是少數(shù)人的游戲（我想COM技術(shù)可能是他的設計者和一部分技術(shù)作者的游戲），難道我們愿意成為計算機的奴隸嗎？通過一種過于復雜的技術(shù)拋棄所有的人其實等于被所有的人拋棄，這么多年中選擇J2EE的人我相信不乏高手，你是不是因為COM的過于復雜才選擇J2EE的？因為它可以用簡單的途徑實現(xiàn)差不多的目標軟件的“二進制”重用、組件化、專業(yè)分工（容器開發(fā)商和應用開發(fā)商的分工）。事實上，你是被微軟所拋棄的，同時，你也拋棄了微軟?，F(xiàn)在讓我們回來吧，我把你帶進了COM的迷宮，現(xiàn)在讓我把你領(lǐng)回來。再讓我們看看COM到底想實現(xiàn)什么目標，其實很簡單，不過是代碼的二進制重用，也就是說你不必給別人源代碼，而且你的組件可以象計算機硬件那樣“即插即用”。我們回過頭來看看Java，其實，這種二進制重用的困難是C+所帶來的（這不是C+本身的錯，而是靜態(tài)編譯的錯），當Java出現(xiàn)的時候，很多問題已經(jīng)不存在了。你不需要一個頭文件，因為Java的字節(jié)碼是自解釋的，它說明了自己是什么樣子的，可以做什么事情。不像C+那樣需要一個頭文件來解釋這些事情；也不需要事先了解對象的內(nèi)存結(jié)構(gòu)，因為內(nèi)存是在運行的時候才分配的。如果我們現(xiàn)在再回過頭來解決COM要解決的問題，你會怎么做呢？首先你會不再選擇C+這種語言來實現(xiàn)代碼的“二進制”重用，其次，你會把所有的語言編譯成同樣的“二進制”代碼（實際上，應當說是字節(jié)碼），這顯然是更聰明的做法，從前COM試圖在源代碼的級別抹平二進制層次的差異，這實際上是讓人在做本來應當由機器做的事情，很愚蠢是嗎？但他們一直做了那么多年，而且把這個痛苦帶給了整個計算機世界因為他們掌握著事實的標準，為了用戶，為了利潤，為了能夠在Windows上運行，盡管你知道你在做著一個很不聰明