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