MFC,一開(kāi)始就錯(cuò)了

1、MFC ，一開(kāi)始就錯(cuò)了MFC ，一開(kāi)始就錯(cuò)了謹(jǐn)以此文祭奠過(guò)去多少年下來(lái)，日日夜夜學(xué)習(xí)MFC源代碼的寶貴時(shí)光。曾經(jīng)以為MFC 是世界上最神圣無(wú)比的東西，發(fā)誓在沒(méi)徹底弄透MFC 之前，絕不越雷池半步，碰都不要去碰LISP 、ERLANG 、PYTHON 、VCL 、ATL 、STL 、LOKI 、BOOST各種美妙的好東西。即使一再聽(tīng)到高人說(shuō)MFC 設(shè)計(jì)得不好，非常糟糕，也都至死而不悔，然后只要稍微聽(tīng)到有人在說(shuō)MFC 的偉大， 心里就特別高興。買了各種各樣的VC 方面的書，什么四大天王、什么幾十百千例、什么VC項(xiàng)目實(shí)例，徹夜苦讀，單步調(diào)試，一次又一次地徘徊在MFC套來(lái)套去的各種美妙代碼之中，觀察里

2、面各個(gè)對(duì)象的值。一次又一次地感嘆 MFC 的偉大，一直在想，這輩子，如果能徹底地掌握 MFC 里面的一切秘密，朕就心滿意足了。終于有一天，終于徹底醒悟，原來(lái) MFC 真不是好東西，不過(guò)就是那些伎倆而已，真不該將它看得如此的偉大。這種念頭一起來(lái)，再回過(guò)頭來(lái)看 MFC 的一坨一坨代碼，只覺(jué)得清晰無(wú)比，又感覺(jué)代碼之中充滿了各種無(wú)奈。 接著再看看那些 VC 方面的書，除了四大天王還稍微有些可取之處，其他的任何一本，奇臭無(wú)比，沒(méi)有一行代碼經(jīng)得起推敲，文筆也糟糕無(wú)比，其內(nèi)容又一再重復(fù)，抄來(lái)抄去，真正是一本又一本的狗屎。感嘆一下：這些書犧牲了多少寶貴的樹木，又折磨死了多少讀者的腦細(xì)胞，實(shí)在罪大惡極。在 MF

3、C 大河日下的當(dāng)今的大環(huán)境之下，在下也不想對(duì)它落井添石，畢竟也在其上學(xué)到不少好東西，特別是閱讀代碼的能力，試問(wèn)這么糟糕復(fù)雜的框架都可以精通，天下還有什么代碼能看不懂（別自信滿滿，你敢碰BOOST 里面的那些奇技淫巧，匪夷所思的幻碼嗎）。但實(shí)在忍受不了軀體內(nèi)另一個(gè)人日日夜夜，旦夕不停的訴求，兼之又一直恨鐵不成鋼，又為自己失去的青春陣痛不已。而VC2008 中 BCG的出現(xiàn)之后， VC2010 還依然保留著那些蠢笨無(wú)比的BCG 文件，不思悔改，終于讓某徹底對(duì)MFC 死心了，這貨沒(méi)得救了。好吧，廢話少說(shuō)，趕緊進(jìn)入正題。國(guó)內(nèi) C+ 界中一大俠說(shuō)過(guò)，任何東西，都要先抓住其主干， 其他的一切細(xì)節(jié)， 都可以

4、留待以后慢慢補(bǔ)充， 否則，一開(kāi)始就陷入細(xì)節(jié)，想跳出來(lái)就不容易了。大俠此語(yǔ)，實(shí)在有道理。（不知為什么，此大俠后期一直在對(duì)C+ 表示不滿，當(dāng)然，人家現(xiàn)在的境界，豈是我等小民所能體會(huì)） 。不說(shuō)其他，就說(shuō)在 C+ 中，必須站在一個(gè)高度上，縱觀全局，才能將一切看得通通透透。于是，下面就嘗試爬上高峰，來(lái)俯瞰 MFC 中的眾生。 MFC 的主干，在下看來(lái)，既不是什么六大關(guān)鍵技術(shù)， 也不是什么文檔視圖結(jié)構(gòu)， 更不是 COM 的封裝，而是為了將原始的 API 中的各種對(duì)象，好比窗口、 GDI 、設(shè)備環(huán)境等，都映射成相應(yīng)的多線程安全的 C+ 對(duì)象，好比將 HWND 搞成 CWnd ，以期減輕 WINDOWS 下界

5、面開(kāi)發(fā)的工作量。這種想法，其實(shí)也無(wú)可厚非，如果真能封裝得好，確實(shí)可以提高生產(chǎn)代碼效率，但是從C+ 和 WINDOWS 的設(shè)計(jì)觀念中來(lái)看，這種映射，還是存在很大的問(wèn)題，稍后再述。問(wèn)題在于， MFC 的實(shí)現(xiàn)，異常丑陋呆板，通過(guò)幾個(gè)全局的線程安全局部變量的映射表，將句柄（Handle，此詞譯得相當(dāng)令人惡心）與其相應(yīng)的C+ 對(duì)象指針形成一一對(duì)應(yīng)，并且指定，在大部分的消息處理和參數(shù)傳遞中，所有的參數(shù)由原本的句柄一律由對(duì)象指針來(lái)代替，然后就高高興興地宣稱已經(jīng)完成任務(wù)了，這實(shí)在讓人哭笑不得。不說(shuō)別的，即使是消息處理， MFC 即使已經(jīng)做了很大的努力，也都無(wú)法將句柄參數(shù)搞成對(duì)應(yīng)的對(duì)象指針，單是這一點(diǎn)，就已經(jīng)失

6、敗了。然后再看看，它最后封裝的做法，不過(guò)是將API 函數(shù)中的第一個(gè)參數(shù)為句柄的都改成相應(yīng)的C+ 對(duì)象的函數(shù)成員，好比將SetWindowText 搞成 CWnd:SetWindowText ，美其名曰，薄薄的封裝。 這真是要笑掉大牙了， 既然是這樣的薄薄的封裝，那還干脆不如不封裝了， 我想破了頭， 也看不出這樣的封裝，帶來(lái)了什么樣的好處。反而將原本全局函數(shù)的各種靈活性，都給葬送在類成員函數(shù)這個(gè)監(jiān)獄中。全局函數(shù)的各種好處，除了是全局這個(gè)缺陷之外，實(shí)在都是類成員函數(shù)沒(méi)法比的。而且，鑒于 API 中數(shù)量實(shí)在太多，于是搞出來(lái)的 C+ 對(duì)象都是龐然大物，最臭名昭著的，當(dāng)然要數(shù) CWnd 和 CDC 這對(duì)

7、黑風(fēng)雙煞了，使用起來(lái)，極不方便，極難學(xué)習(xí)。一個(gè)類的函數(shù)過(guò)多，無(wú)論如何， 都是失敗的設(shè)計(jì)。 還有，如果 WINDOWS 系統(tǒng)新增了什么使用到句柄的函數(shù)，這些類也都要相應(yīng)地增加新成員函數(shù)，再進(jìn)一步說(shuō)，如果用戶自己因?yàn)樾枰?，也要開(kāi)發(fā)使用到句柄的全局函數(shù)，要怎么想辦法整成員函數(shù)呢。其實(shí)， MFC 中的所謂的線程安全， 其實(shí)也不過(guò)是自欺欺人的說(shuō)法而已，你要想在 MFC 中多線程的使用窗口對(duì)象，即使不是不可能，那也要花費(fèi)九牛二力氣才能在多線程中共享窗口對(duì)象，一切皆只因 MFC 已經(jīng)很努力地做到了不讓你在多線程下使用窗口對(duì)象。好了，再進(jìn)一步考察，在這種思路的指導(dǎo)下，最后MFC 被設(shè)計(jì)成一個(gè)什么樣的框架。一直

8、很懷疑想，MFC 的設(shè)計(jì)者，是否不是對(duì)WINDOWS API的精神了解得不透徹，又或者對(duì) C+ 不是很精通，否則，無(wú)論如何，斷斷都不會(huì)整出 MFC 這樣的一個(gè)人不象人、鬼不似鬼，精神分裂、做事虎頭蛇尾的鬼東西出來(lái)。要不然，我們用MFC 開(kāi)發(fā)，就不會(huì)覺(jué)得束手束腳，很不好施展拳腳，一再感覺(jué)一直受制于其可惡的呆板的框架之下，這并不是說(shuō)框架不好，只是MFC這套框架，實(shí)在很不好擴(kuò)充。這樣也罷了，問(wèn)題是，MFC 在使用上，又很不人性化，你又要陷入各種各樣的細(xì)節(jié)之中，什么二段構(gòu)造，有些對(duì)象又要自己刪除，有些又不能自己刪除等，更要命的是， MFC 的運(yùn)行效率又臭名昭著。有些同學(xué)就會(huì)問(wèn)，貌似在MFC 開(kāi)發(fā)，其實(shí)

9、也很強(qiáng)大很靈活，殊不知這種強(qiáng)大和靈活，那都是源于C+ 的強(qiáng)大靈活，也源于WINDOWS 系統(tǒng)的強(qiáng)大靈活，源于MFC 只對(duì) API 只作了一層薄薄的封裝，與MFC 本身的設(shè)計(jì)沒(méi)什么太多的關(guān)聯(lián)。當(dāng)拋開(kāi) MFC ，直接用 API 和 C+ 來(lái)寫代碼，就體會(huì)到什么才叫做強(qiáng)大靈活，除了代碼比MFC 多一點(diǎn)之外，一切都要比MFC 來(lái)得清爽， 也要來(lái)得容易維護(hù)。 如果，如果設(shè)計(jì)做得好，可能總體的代碼量不會(huì)比用MFC 的多也說(shuō)不定。于是，這么一個(gè)偉大的框架，表現(xiàn)出來(lái)的，很多地方都 C+ 的精神格格不入。承然， MFC 剛開(kāi)始設(shè)計(jì)時(shí)， 缺乏太多的 C+ 的特性的支持，而不得不另起爐灶。但是，就算沒(méi)有 C+98

10、中的功能支持，MFC 也不該出現(xiàn)以下這么重大的設(shè)計(jì)問(wèn)題。1、 不需要用到的特性，我們依然要付出種種代價(jià)。我們看到 CCmdTarget 集成了 COM 的功能， CWnd 中對(duì) ActiveX 的支持，就算我們的代碼不包含一丁點(diǎn)使用到COM 的代碼，我們都要背負(fù)每個(gè)CWnd 中將近 100 個(gè)字節(jié)的大小， 運(yùn)行過(guò)程中一再要忍受框架代碼中對(duì)ActiveX 變量的一次又一次地檢查。我們看到，就算不使用文檔視圖結(jié)構(gòu)，CMainFrame中都要承受對(duì)它的支持代碼，和各個(gè)不必要的成員變量?？傊琈FC 中有很多特性， 就算不愿意使用， 它們還是在那里，不容許我們忽視。2、 耦合太厲害。我們看到， CWn

11、d 中居然出現(xiàn)了對(duì)子類 CView 和 CFrameWnd 的引用， CControlBar 的成員函數(shù)中有對(duì) CToolBar 的 CAST ，然后， CFrameWnd 又引用到CControlBar 和 CView ， CControlBar 和 CView 也都用到 CFrameWnd 的函數(shù)，各種各樣好厲害的循環(huán)依賴， 這么糟糕的設(shè)計(jì)竟然出現(xiàn)在 C+ 的著名的界面框架，不得不令人嘆息不已。這樣的耦合，就是在MFC 之中，一個(gè)類設(shè)計(jì)得再好，也只能在某些特定的場(chǎng)合下使用。好比，CControlBar,CSplitterWnd 這兩個(gè)好東西只能活在CFrameWnd ，CView 的環(huán)境下

12、，想在其他的地方使用上就煞不容易了。就算是著名的文檔視圖結(jié)構(gòu)，也都是問(wèn)題很大，如果我的類，想要訂閱文檔中的通知消息，還要求必須派生于CView 中，這個(gè)限制也太厲害了，于是為了它這個(gè)死板的設(shè)計(jì)，有多少次，我們必須改變?cè)O(shè)計(jì)，以適應(yīng)MFC 的無(wú)理取鬧的要求。3、 功能太過(guò)單?。?MFC 僅僅是作為一個(gè)界面的基本框架而已，僅僅實(shí)現(xiàn)了從句柄到對(duì)象的映射，然后，再加上一點(diǎn)點(diǎn)所謂的文檔視圖的MVC 模式，必要的多視圖多子窗口的支持，基本的必要的COM 支持，對(duì)API 的薄薄封裝，僅此而已（至于 SOCKET 、WININET和數(shù)據(jù)庫(kù)的MFC 類，又有多少可利用的價(jià)值） 。有多少次，我們想對(duì)對(duì)話框進(jìn)行拉伸的

13、操作；有多少次，我們需要用到表格控件； ，但是，這一切，想要MFC 提供更加強(qiáng)大的控件，完全都沒(méi)有。必須求助于第三方控件公司庫(kù)，好比，BCG 、XTREME ，你們知道，MFC 的代碼就算再爛，也還是很有分寸，還能保住最基本的底線，但是，第三方控件的代碼，那真的是，讓人大驚失色，沒(méi)有做不到的，只有想不到的。要知道，C+ 可是很強(qiáng)大的，但是，用它做出來(lái)的框架，卻如此的功能之小。4、 MFC 中的類的功能不單一，承載了太多的責(zé)任，導(dǎo)致很容易就出現(xiàn)了很多重復(fù)的代碼：好比CCmdTarget 中原本只是為了可以處理消息，后來(lái)居然還兼具COM 的功能。又好比，CList, CMapPtrToPtr 里面

14、又都包含了內(nèi)存池的實(shí)現(xiàn)代碼，原本這些內(nèi)存池的實(shí)現(xiàn)代碼就應(yīng)該剝離出來(lái)。5、 行為錯(cuò)亂，神經(jīng)分裂，沒(méi)有統(tǒng)一的接口，以至于使用起來(lái)，極易出錯(cuò)。很多地方，都努力地去做了，但是都做得不徹底。企圖封裝所有的WINDWOWS的界面的 API ，但無(wú)論如何，都做不到，而且它自己內(nèi)部也都知道沒(méi)辦法做到，但它還要努力地去做。各種各樣的問(wèn)題，難怪MFC 的書那么多，沒(méi)有一本可以作為面向?qū)ο蟮牡浞秾W(xué)習(xí)，即使四大天王，也不過(guò)只是沒(méi)有那么惡臭而已。原來(lái)一切，皆只因?yàn)樵搭^本就臟了。之前還以為， MFC ，還能算是一積心堆砌而成垃圾。總體設(shè)計(jì)，雖然確實(shí)糟糕透頂，但細(xì)微上看，還能做到讓人擊節(jié)贊嘆，好比對(duì)于線程局部變量的封裝擴(kuò)展，消息映射表。 可是，即使局部代碼的實(shí)現(xiàn)，也都充滿了重重的缺陷。如果說(shuō) MFC 還有些可圈可點(diǎn)之處，VC2008 之后引進(jìn)的 BCG