算起來(lái)，我用Visual C++也有將近5年的歷史了。在這期間，我也曾涉獵過(guò)Visual Basic和Delphi，但都是淺嘗而止；Visual C++始終是我的主業(yè)。可是努力的成果如何呢？我用Delphi作出了十多個(gè)有規(guī)模的軟件，用VB－－雖然我用在VB上的時(shí)間只有短短的兩三個(gè)月－－也有兩個(gè)像樣的項(xiàng)目；然而，在我付出了最大熱情和最多努力的Visual C++上面，卻只作出了三個(gè)自己看得上眼的軟件。
固然，在用Visual C++的時(shí)候，MFC幫了我不少的忙。但是，在寫下這個(gè)題目之時(shí)，我就已經(jīng)打定主意：在這篇文章中，只對(duì)MFC提出批評(píng)，不說(shuō)MFC的好話。Visual C++的擁護(hù)者且慢發(fā)難，聽(tīng)我道出其中原因。我注意到，象候捷先生這樣對(duì)MFC極其熱愛(ài)的著者，在其大著《深入淺出MFC》中對(duì)MFC的評(píng)價(jià)也是盡量的做到客觀和公允；而大師Charles Petzold和Jeff Prosise，在他們的作品中也只是給予MFC以謹(jǐn)慎的贊美。Charles Petzold還很客氣的指出了MFC的局限。然而另外一些編程書(shū)籍的作者，特別是某些國(guó)內(nèi)的作者，似乎毫不吝惜把最華麗的語(yǔ)言和最夸張的贊美賦予 MFC，從書(shū)架上任意翻開(kāi)一本介紹Visual C++的書(shū)籍，看看它的前言和序章，往往充斥著讓人目眩的溢美之辭。多少初學(xué)者被這些充滿暗示和誘導(dǎo)的辭令吸引，以為MFC是完全可視化的，象VB一樣容易掌握的東西，當(dāng)他們深入以后，會(huì)不會(huì)有上當(dāng)?shù)母杏X(jué)呢？我痛恨一切不負(fù)責(zé)任的夸大和炫耀，特別是只為了增加書(shū)籍銷量而不惜昧著良心說(shuō)話的作者，而我的感覺(jué)是現(xiàn)在這樣的作者和書(shū)籍似乎已經(jīng)泛濫了。本著矯枉必須過(guò)正的指導(dǎo)思想，我的目的很明確，就是要批評(píng)MFC。對(duì)Visual C++和MFC非常熟悉的讀者，我無(wú)慮您對(duì)本文提出批評(píng)和指責(zé)，因?yàn)槟鷮?duì)MFC已經(jīng)有了自己的觀點(diǎn)，不會(huì)為我所誤導(dǎo)；對(duì)Visual C++的入門者，我希望您在聽(tīng)夠了對(duì)Visual C++和MFC的贊美之后，來(lái)聽(tīng)聽(tīng)另一種聲音，即使它并不完全正確（甚或是充滿謬誤），至少能讓您帶著自己的思想來(lái)看待您將要學(xué)習(xí)的東西。
對(duì)MFC的批判之一：不支持屬性，MFC憑什么同其他語(yǔ)言抗衡？
竊以為在編程語(yǔ)言中引入“Property”的概念是在面向?qū)ο蟮木幊趟枷牒笞顬橹卮蟮母镄轮弧Ｆ鋵?shí)，目前市場(chǎng)上絕大部分編程語(yǔ)言，包括VB, Delphi,C++Builder和PowerBuilder等等都支持Property。程序員只要簡(jiǎn)單的修改對(duì)象的屬性，就能夠完成相當(dāng)部分的工作，不僅是減少了無(wú)謂的勞動(dòng)，更重要的是減少了出錯(cuò)的機(jī)會(huì)，并且使得生成更復(fù)雜的界面和完成更復(fù)雜的工作成為相對(duì)容易的工作。我想絕大部分人會(huì)同意，如果去掉了Property這個(gè)東西，那么象VB和Delphi這樣好的RAD，包括Microsoft一直倡導(dǎo)的ActiveX，都會(huì)失去了絕大部分的魅力。這個(gè)道理，Microsoft應(yīng)該是在推出Visual Basic 1.0的時(shí)候就認(rèn)識(shí)到了。可是自從Visual C++誕生到現(xiàn)在，它似乎絲毫沒(méi)有使用Property的意思，雖然Visual C++這個(gè)名字在很大程序上沾了它的長(zhǎng)兄Visual Basic的光，不過(guò)它并沒(méi)有從VB那里學(xué)到如何讓編程更簡(jiǎn)單和更輕松的秘訣。
有人可能會(huì)說(shuō)，data member of class不是property嗎？不是的，如果你用過(guò)C++Builder的話你一定能明白這種分別。MFC從來(lái)就不支持Property，而且今后看來(lái)也不會(huì)了，這意味著用MFC，你還是得干苦力活。(ActiveX？不錯(cuò)，ActiveX支持Property，而且MFC支持ActiveX開(kāi)發(fā)，不過(guò)這并不是三段論發(fā)揮作用的地方。)
對(duì)MFC的批判之二：?jiǎn)握{(diào)的處理方式使本來(lái)應(yīng)該簡(jiǎn)單的工作變得復(fù)雜
應(yīng)該沒(méi)有人反對(duì)這樣的觀點(diǎn)：用Visual C++開(kāi)發(fā)界面，特別是不符合Microsoft所謂“標(biāo)準(zhǔn)”的程序，比VB，Delphi或是C++Builder都要慢得多。（附帶說(shuō)一句，我不知道 Microsoft制定Windows Logo標(biāo)準(zhǔn)，并且要求程序員遵守的依據(jù)是什么；我自己的程序99％以上都不符合這個(gè)標(biāo)準(zhǔn)。）可這是為什么呢？是C++語(yǔ)言在這方面的天生不足？肯定不是。
在我看來(lái)，罪魁禍?zhǔn)资荕FC中的CDocTemplate，這個(gè)類規(guī)定了一種非常死板和機(jī)械的機(jī)制，即一個(gè)Document，一個(gè)View和一個(gè)FrameWnd綁定在一起。遺憾的是，實(shí)際情況往往復(fù)雜的多。對(duì)界面稍微稍微要求高一點(diǎn)的程序大多要求一個(gè)Document有多個(gè)View，甚至在某些程序中，希望在同一個(gè)View中顯示多個(gè)Document的內(nèi)容：比如，將兩個(gè)公司的業(yè)績(jī)放在一起作比較。對(duì)View和FrameWnd的關(guān)系也有類似的情況。然而，DocTemplate的機(jī)制使得這樣并不高的要求變的相當(dāng)困難。想實(shí)現(xiàn)你的要求嗎？可以。你要添加新的View類。你要從默認(rèn)的 IDR_MAINFRAME復(fù)制資源到新的類中。你要用AddDocTemplate添加自定義模板。你要用
GetFirstDocTemplatePosition和GetNextDocTemplate檢索模板列表。你要用GetDocString察看每個(gè)模板是否符合你的要求。你要重載CFrameWnd::OnCreateClient以派生新的視圖。你要用CView::SetDlgCtrlID和 CFrameWnd::SetActiveView以及CFrameWnd::RecalcLayout來(lái)在各個(gè)視圖中切換。你要用未公開(kāi)的 CDocManager管理文檔模板。你要...還要嗎？反正我是怕了。
對(duì)MFC的批判之三：固步自封，不思進(jìn)取
MFC 可以作為固步自封的活教材。別忘了，MFC是和Borland OWL同一時(shí)代的產(chǎn)物（還有多少人記得OWL呢？）當(dāng)然，這不是MFC的錯(cuò)誤。不過(guò)，如果以個(gè)類庫(kù)的體系自從2.0版本以來(lái)就沒(méi)有絲毫改變，是不是意味著這個(gè)類庫(kù)已經(jīng)臻于完美了呢？不，即使Microsoft也不敢這么狂妄。但事實(shí)是，MFC的體系從MFC2.0以來(lái)就沒(méi)有變動(dòng)過(guò)。每個(gè)版本的更新，不過(guò)是增加了一些新類，某些類的接口稍作修改，僅此而已。不，不要把ATL作為MFC的改進(jìn)；ATL從來(lái)就不依賴于MFC。
誰(shuí)都知道在這幾年中C++語(yǔ)言有了多么大的改進(jìn)。包括RTTI，Dynamic Creation，Exception，Standard Template Library等等都成為新的C++標(biāo)準(zhǔn)的一部分。不過(guò)，Microsoft好像并不喜歡這些新東西，它的做法是另起爐灶；于是在同以套Visual C++中就出現(xiàn)了兩套互不兼容的實(shí)現(xiàn)。平心而論，在新的C++標(biāo)準(zhǔn)出臺(tái)前，Microsoft自己實(shí)現(xiàn)這些機(jī)制實(shí)在是一個(gè)相當(dāng)了不起的創(chuàng)舉；但是歷史總是在發(fā)展的，MFC為什么不從善如流，盡量利用語(yǔ)言中已經(jīng)實(shí)現(xiàn)的功能，而非要固執(zhí)的用自己的一套老辦法？事實(shí)上，MFC幾乎沒(méi)有用到新的C++方案中任何有益的元素－－盡管這些方案已經(jīng)對(duì)MFC庫(kù)中很多問(wèn)題提出了相當(dāng)完美而且精練的解決方法。
對(duì)MFC的批判之四：天然的傾向性
不知道您對(duì)AppWizard生成的默認(rèn)項(xiàng)目有什么感覺(jué)。反正我的感覺(jué)是：這種工程就是用來(lái)開(kāi)發(fā)象Word，Excel這樣的程序的。好像MFC天然的就傾向于這樣一種程序。但事實(shí)上，這種程序少之又少。
在Microsoft 看來(lái)，好像每個(gè)程序都應(yīng)該有一個(gè)File菜單，而且這個(gè)菜單下面一定應(yīng)該有New,Open,Save,Exit這些選項(xiàng)。在我的實(shí)際經(jīng)驗(yàn)來(lái)說(shuō)，我只搞過(guò)一個(gè)程序符合這樣的要求。有多少人真的要搞一個(gè)自己的字處理程序或是電子表格呢？對(duì)于很多常見(jiàn)的、基于數(shù)據(jù)庫(kù)的程序，你需要New，Open和Save 嗎？如果是基于網(wǎng)絡(luò)的程序呢？特別是在多媒體程序和游戲程序中，MFC生成的框架與其說(shuō)是幫助，不如說(shuō)是累贅。
這倒是符合Microsoft的一貫風(fēng)格：你要的只是特定的功能，它卻一并塞給你一大串不相干的東西，并且在很多時(shí)候，這些不相干的東西反而成為麻煩制造者。于是，我不得不在新生成一個(gè)項(xiàng)目后，不辭勞苦的去掉AppWizard“慷慨”的贈(zèng)送品，包括大量無(wú)用的菜單和工具條按鈕，然后才能開(kāi)始實(shí)際的工作。說(shuō)實(shí)在的，AppWizard在為我減少工作量的同時(shí)，也增加了我不少勞動(dòng)量。
MFC定義了一個(gè)Document-View框架，并且把Document定義的相當(dāng)寬泛，幾乎可以代表任何數(shù)據(jù)。但是在實(shí)現(xiàn)上，Document是相當(dāng)狹窄的；比如Document定義的Serialize固定的與一個(gè)CArchive對(duì)象聯(lián)系在一起，而CArchive又固定的與一個(gè)CFile聯(lián)系在一起，這樣實(shí)際上就限定Document處理的對(duì)象只能是磁盤文件。況且，在一個(gè) Serialize中處理所有數(shù)據(jù)的序列化也是一種相當(dāng)機(jī)械而死板的機(jī)制：它只能處理小量而且是一次處理完畢的數(shù)據(jù)，而實(shí)際上，程序往往要處理大塊的數(shù)據(jù)，并且不可能一次完成。在這種情況下，CDocument的處理機(jī)制反而是個(gè)障礙。此外，在很多類型的程序中，CDocument扮演的是一個(gè)很尷尬的角色：比如在絕大部分?jǐn)?shù)據(jù)庫(kù)程序中，CDocument完全是個(gè)雞肋，實(shí)際的數(shù)據(jù)處理只能靠CRecordset來(lái)完成；再比如說(shuō)，在最典型的Doc- View程序－－就是記事本程序－－中，CDocument根本是個(gè)無(wú)能的東西，因?yàn)樗嫒?shù)據(jù)反而要求助于CEditView:: SerializeRaw。
Doc-View框架有可能突破這些限制嗎？完全可能。不過(guò)，你要有心理準(zhǔn)備，如果你要這么作，你就必須求助于一大堆的未公開(kāi)函數(shù)和類型，這些東西完全沒(méi)有文檔，依賴于你對(duì)MFC“底下的東西”究竟有多么熟悉，以及你是否愿意鉆研MFC的源代碼－－在絕大多數(shù)情況下這不是一件愉快的工作。如果你使用這些未公開(kāi)的東西出了問(wèn)題，或者你不知道如何使用，對(duì)不起，Microsoft不會(huì)給你任何支持－－誰(shuí)教你不按照 Microsoft的邏輯工作來(lái)著！
對(duì)MFC的批判之五：什么是封裝？
好像這不成為一個(gè)問(wèn)題。但是對(duì)MFC而言，封裝的定義是不成立的。這句話的意思是說(shuō)，如果你不想生產(chǎn)玩具的話，如果你需要調(diào)試程序的話，如果你的代碼需要有比 AppWizard更多的東西，那么，MFC對(duì)你來(lái)說(shuō)就不是封裝的。如果你的程序運(yùn)行出了錯(cuò)，對(duì)不起，問(wèn)題不在你的代碼里面，而在MFC庫(kù)的某個(gè)文件中， Visual C++會(huì)為你打開(kāi)這個(gè)文件，至于“為什么會(huì)出錯(cuò)？”“這個(gè)函數(shù)究竟是用來(lái)干什么的？”MFC不會(huì)給你答案，你自求多福吧。如果你除了MSDN中的公開(kāi)文檔以外，對(duì)MFC的源代碼從不關(guān)心，那么恭喜你，你是個(gè)快樂(lè)的程序員，但是你永遠(yuǎn)不能生產(chǎn)出真正有用的程序。
候捷先生在其著作《深入淺出MFC》中也曾提到：或許有人會(huì)產(chǎn)生疑問(wèn)，追尋“黑盒子底下的東西”，豈不有違面向?qū)ο缶幊痰某踔裕康菦](méi)有辦法，不去熟悉MFC的源代碼，永遠(yuǎn)只能生產(chǎn)玩具。候先生說(shuō)的很委婉，盡量不批評(píng)MFC。但是，我可以這樣說(shuō)：使用VB,Delphi,C++Builder，Java這些語(yǔ)言的程序員幾乎從來(lái)不去關(guān)心類庫(kù)的源代碼，可是這些語(yǔ)言并不是用來(lái)生產(chǎn)玩具的！