MFC為什麼難用，框架的敗筆是？

01-15

討論MFC框架設計

「產品是好的，只是出現的時間早了。」這話怎麼能這麼偷換概念呢？這話是用來說產品超出了時代給予的基礎，沒能爭取到第一批用戶，失去了發展的機會。

MFC 沒爭取到第一批用戶嗎？顯然不是。MFC 可不可以發展，完全可以。你看 C# framework 兩年一改的盡頭，如果 MFC 在 3.0/4.0 的時候把那個破爛的 MESSAGE_MAP 改成 virtual function，把封裝方式改的合理一點，是完全沒有問題的。Microsoft 那時候對開發者完全是綁定的態勢，它說什麼是什麼。到了 Java, iOS, Mac 都有能力和它搶開發者的時候，它倒不管不顧的隨便改起來了。你說這是什麼？

然而VCL和MFC是屬於同一時代的東西，為什麼人家做的就各種好用呢

MFC的敗筆就是出現的太早，那個時候距離第一個C++標準還非常遠。儘管MFC在剛出生的那個年代是全球最先進的，然而C++發展得比MFC更加迅猛，結果MFC一些好的東西就變成了陋習（e.g.，Google喜歡的兩階段構造，跟MFC的做法如出一轍），於是越來越糟糕。

如果好好看看MFC的話，就知道他那個時候都已經有MVVM的想法了，無奈當年的C++是根本無法完成data binding這麼複雜的工作的（Release/Tutorial/GacUI_HelloWorlds/MVVM/UI at master · vczh-libraries/Release · GitHub），所以儘管什麼都有，但是交換數據竟然用的是交換變數（其實這就是全球第一代data binding，哈哈哈哈哈哈）和一個幾乎沒有調度的調度函數。這一思想其實影響深遠，幾乎後來所有支持MVVM的GUI都是這個想法，包括199x年在Office內部誕生的UI庫，以及被.net抄過去之後搞的Avalon和WPF，還有在WPF誕生了10年之後，畫網頁領域終於開竅了搞出來的一些譬如angularjs的東西，都集成和發揚了MFC的思想。

但是，MFC的細節還是太陳舊了，所以不要用了。

本人一直使用MFC，用多了，習慣了，原生控制項呆板，是短板，如果注重功能而不是漂亮，這沒有關係；如果要漂亮，需要美工畫圖，貼圖片；很多情況下，都需要根據類庫中的控制項定製特殊功能的控制項；用mfc開發，最浪費時間的就是特殊控制項的定製開發；我做android開發也是一樣，特殊UI效果，也需要分析內部機制，開發定製的控制項；我感覺，你覺得某些UI庫好，可能是庫里提供了很多現成的控制項或工具可用，當遇到一些無法滿足需要的時候，還得自己寫；不管一個UI庫再好，總會有不能滿足需要的地方；UI本質上都是由控制項一層層堆的，UI編寫，重點還是控制項編寫；封裝較好，控制項豐富，華麗，容易上手，比較招人喜歡；但是，一點你做項目，你會發現，不管什麼庫，都得自己定製，mfc較老，很多東西都需要代碼實現，效率不高；mfc裡面的一些思想，目前其它UI庫裡面也是採用的；mfc的確有些設計不好的地方，可能是當時歷史局限，也可能是為了敢工，微軟程序員偷懶了；mfc的設計與其它UI庫設計相比很另類，不直觀，對初學者燒腦；

不談具體需求談工具都是耍流氓。用戶場景變了，一個工具能不能用都難說，談什麼好不好用？比如一般人買菜用簡單的計算器，但是對我這種數學系畢業的人完全沒用——心算就可以搞定了。比較強大的科學計算器應用手機上不是沒裝，但是對於上街買菜這個用戶場景來說，無論是對一般人還是對我這種數學系畢業的人，應該還沒有功能少的簡單計算器好用。

正常人判斷類庫好不好用時候都是去看文檔全不全，擴展是否容易，代碼bug多不多，性能好不好等等。至於MFC內部怎麼實現的，那更多是BCG/Codejock這樣的公司需要關心的事情。你的用戶會給你「用MFC我就要退錢」這種需求嗎？還是會給你「下載大小不超過10兆」或者「要在1G內存，集成顯卡的上網本上流暢運行」這種需求？至於覺得MFC提供的架構過時——你創建程序的時候可以不選擇Doc/View的。

假如你是項目經理，了解市面上現有的各種輪子，以及了解你的用戶想要什麼樣的輪子，是你自己造輪子之前需要做的工作。脫離具體使用場景，談工具好不好用或者能不能用是空中樓閣。

==題外話==

使用一個技術之前建議搜索人們對它的抱怨，比如"MFC sucks"或者"QT sucks"。不suck的技術是沒人用的技術，你選擇要做的是看看那些人抱怨的事情是否影響到你完成你的用戶需求，這樣的deal breaker越早發現越好。

早不是問題，同期的owl，vcl相當好用。

所以，問題是當時微軟的水平（專註投入程度之後的結果），在編程介面/框架設計、IDE設計方面，遠遜於borland這樣的公司。

vcl也是基於win32 api，但是封裝隱藏得非常到位：

初級開發者、新手，不懂api也能快速實現——像用vb；

高級開發者、老手，可以直接用api在現成的框架上實現特殊、框架未考慮的功能效果——像用vc。

而最後的編譯結果，還可以非常綠色（一個exe走天下，部署簡單），運行效率也與vc幾乎一致

從這種框架的效果，最能看出框架設計者的水平、功底：不但自己要有水平，還要能考慮照顧到開發者（框架的使用者）的水平和便利

MFC之所以難用，主要原因如下：

1. 只對API簡單封裝，Windows API學習曲線本來就很陡峭。

2. 對入門新手不友好，如添加消息處理函數，不像同門VB和別派Borland系雙擊即可。

3.不自畫的話，界面很土，雖然當年codeproject等網上資源不少，但開發效率明顯不如其它框架。

4. 深入看源碼，各種宏，由於c++標準滯後，微軟把奇巧淫技用到了極致。說實話代碼很難看。

5. 微軟一貫的、喪心病狂的完美兼容，造成各種尾大不掉。歷史包袱太大。

寫了1、2、3、4、5、後，發現說的不是myfreecams...

此一時彼一時。那個年代剛剛發明了面向對象編程，所以高大上的微軟公司用上高大上的編程思想。那時解決有無的問題，所以那時候就是正確的選擇。可是今天看來就是錯誤的，發明成千上萬的類，學習到何時是個頭。

https://zhuanlan.zhihu.com/p/21962282?from=timelineisappinstalled=1

輪子哥都來了,火鉗劉明啊...

MFC除了太老了以外,其他一切均好...

當年我第一次看到MFC的時候,多驚為天人吶...

深深的感慨...

卧槽,這居然可以這麼寫...

卧槽,這樣寫也行...

包括現在,我去看MFC的代碼...我依然覺得這是人類智慧的結晶...

我覺得它裡面的很多思想放到現在來說都不落伍...

我認為,你說他不好用,只是因為出現了更傻瓜化的東西...

就好像老式的海鷗相機...當年90年代我每次看到他都是充滿羨慕嫉妒恨的眼神的...

如今我再看到他就只是一個收藏品了...

就品質而言,它差嗎?它劣質嗎?只是時代變了而已...

MFC對於熟悉windows api的人來說，很容易使用。

覺得MFC難用，說明：你不熟悉windows api編程。

MFC沒有敗筆的地方，整個框架設計的定位，是簡化windows api的開發，對windows api進行了一層薄封裝後，再加入各種實用的類，如容器，字元串，文件網路等，使開發windows程序更加快捷簡單。

那些覺得難用的朋友們，別指望不懂windows api就學會MFC，這本來就是錯誤的途徑。

MFC相較於其他框架VCL，QT等，缺少了抽象層，太過於貼近windows api，所以指望直接學習MFC會感覺吃力。

本老農十幾年前老用這個，後來轉道javaweb，也不知道現在windows c++世界都流行啥了。列舉幾點：

1.封裝的太厚，限制多，反而讓人很難深入定製。後來索性用chtmldialog了;

2.生命周期的不一致性，createwindow/destroywindow什麼的

3.封裝的不徹底，為了能與winapi通上話，attach，detach一大堆。。。

每次用Java構建框架的時候都會懷念mfc。。。

我覺得MFC的問題是，除非你學會Win32 API，否則你用著大概很痛苦和莫名其妙。可如果你用了Win32 API，幹嘛還要用MFC包這一層？直接調用API不就行了。

我也覺得不好用，好吧，是我不會用……努力學習中

太複雜，太難學，

感謝MFC，終於可以名正言順多花一倍的時間，來調BUG

敗筆就是：太醜陋了。

各種奇怪的宏、消息綁定什麼的

作為用戶，要了解很多不必要的東西。

不僅要學習框架，還要學習框架的缺陷。

理想情況當然是用寫網頁的方式寫桌面應用。

用過mfc寫程序，可能是自己理解的不夠深入吧，用的時候沒有感覺太難，不過比起qt之類的還是複雜不少