引述
VB, Delphi, BCB 和 C++/MFC 的抉擇 (下)
使用 MFC 和使用 VB 或是 JAVA 有很大的差別，最主要是程式設計者需要了解 WIN32 的運作模型， MFC 物件在使用時需要根據 WIN32 運作模型來操作，否則物件一律會以 ASSERT 失敗的下場來結束程式，例如：WIN32 視窗沒有真正開啟在螢幕之前，是不可以產生 Timer 物件的，也不能存取其 DC 結構，又如 C++ 的 MFC 物件和其相對應的 WIN32 物件是必須透過兩階段的步驟來建立連結的，如果沒有做第二個階段 Create 的動作的話， C++ 裡的物件是完全不能操作的等等。而物件類別的線上說明通常不見得會解釋 WIN32 的運作模型，這使得學習 MFC 的門檻更加提高。反之 JAVA 或是 VB 的包裝就比較完善了，程式設計者不太需要了解 WIN32 系統運作的細節， (除非在 VB 中你需要使用 WIN32 API 自行設計功能時你才需要去深入了解 WIN32 系統)，就可以快樂地完成所要製作的視窗界面了，所有的細節都已經被包裝好了，有適當的初始值與固定的執行時機。從另一個觀點來看，包裝當然使得使用容易，但是功能也就受到限制，效率也會打一點點折扣，這些都是挑選軟體環境必須注意的事項。不過在評估 VB 和 MFC 時，相信功能及效率可能都不會是最大的考慮點，軟體的架構、軟體的生命期、維護性、擴充性、與重用性才是決定的關鍵。如果你只是寫單一一個具有視窗界面的程式，系統本身運作模型很單純，你根本也沒有打算維護或是擴充它，那當然用 VB 來撰寫，可以得到最快的成果，因為它本來就是一個所謂的快速程式發展 (Rapid Application Development, RAD) 的環境。
最後，物件導向原理、 C++ 程序式與物件式併存的騎牆派設計、 WIN32 的運作原理，這三者造成了學習 MFC 的超高門檻，熟悉的人真的少之又少，也使得商業性軟體在評估各項投資與可能的報酬時，更加傾向於 VB，如果說 VB 應用程式在軟體規格變更時需要投資很多的人力去進行更改或是重新設計，那麼也是軟體公司老闆該頭痛的事，對於眾多的 VB 程式設計員來說反倒是保住飯碗的大利多囉!? 這些經濟社會層面的角力，明顯與技術層面的認知相左，在這裡只能說 WIN32 死亡的時候， MFC 和 VB 都將無一倖免，但是 C++/MFC 應用程式還保有 C++ 物件式系統的核心，換個圖形界面平台還能很快地恢復運作，但是 VB 程式的話就得看微軟公司的意向了。
VB 4.0 放棄了對 16bit VBX 的支援而改支援 32bit OCX 曾經是很多 VB 設計者的夢靨，如今微軟也不打算再推出 VB 7.0 了， 2001 年改推出 VB.NET 來取代，微軟在 VB.NET 中加入了嚴格的型態檢查，加入了物件導向的支援，說真的， VB.NET 的學習門檻一定提高了許多，真的也不能稱它為 BASIC 了，那 Visual Advanced 如何?! 2000 年下半年微軟推出的 C# 也是另一個物件導向佔上風的表象，大家真的需要仔細去評量一下才是，趁著你還在學校，沒有工作/薪水的壓力，有老師和同學可以討論的時候，趕快學習物件導向的概念，不要以為工業界短視的狀況會是不會改變的，等到老闆撐不過去的時候，你終究還是犧牲者的。
附帶一提的是 Delphi 和 BCB 基本上都是 RAD，比起 VB 好一點的是一個基於物件導向的 PASCAL，另一個則是基於 C++，都有物件導向的支援，也都有嚴格的型態系統支援。
附註：學習 MFC 除了練功之外，有沒有什麼直接的好處呢?
我想應該是藉此學習 C++，學物件導向分析、設計、程式製作，學視窗系統運作的原理，直接設計繪圖，可以設計多緒程式，可以用 D3D, OpenGL，另外有一件事可以給大家參考的是幾乎在所有的嵌入式系統中 C++/C 都是標準的設計語言，沒有 VB 這樣的環境喔。
>> VB, Delphi, BCB 和 C++/MFC 的抉擇 (上)
