Abstract
目前開發Windows程式的方式很多，除了VB、Delphi、BCB與MFC外，.NET和Java也可以，甚至跨平台的Qt與GTK+等也可以，這篇文章雖然是2001年有點久遠(7年前)，不過觀念卻很正確，也剛好點出了很多一般人錯誤的觀念，值得一讀。

Introduction
轉貼自http://squall.cs.ntou.edu.tw/winprog/VBvsCPPMFC.html

這是一個我不太喜歡談的決策問題，一直很希望由資訊系出去的學生都能夠了解製作軟體的各種方法， Basic, C, PASCAL, FORTRAN 這些語言無疑是相當基本的了，但是程式語言還有功能式 (functional) 的，物件導向式 (object oriented) 的，宣告式 (declarative) 的，在各個應用領域中享有自己的一片天地，可以讓大家深入地感受到軟體的能力。

在現實面上，程序導向和物件導向算是比較一般化的，其中程序導向語言製作的軟體仍然佔有最大的應用市場，也許程序式的運作模型最能被大家接受，最容易隨性地發揮，與現今 von Neuman 架構機器最能夠匹配，也許物件導向的方法太過嚴謹、太過抽象，在這種狀況下真的很難去說服同學說其它沒有被市場廣泛接受的軟體方法中擁有無限的希望，用心、下些苦工去了解他們是不會讓你後悔的；想說得嚴重一點，沒有了解各種軟體方法的話，也許資訊系就白走一遭了，可是也深深地知道市場早已證明，許多的從業人員不需要知道軟體製作的各種奧祕，只要精通程序式/結構化的軟體方法，在工商業界中已經可以無往不利了，真的看不出 von Neuman 型態的計算機模型會很快地消失，會有所謂物件化的硬體模型嗎? 所以真的也不預期程序式的程式製作方法會像史前的恐龍一樣受迫消失。

那麼物件式模組化、與應用領域緊密結合、由下而上 (bottom up) 的軟體製作方法是不是就永遠限於大規模、大成本、複雜、專業的軟體呢? 這些方法會的人少，資源也少，就好像叫好不叫座的電影一樣，讓所有的影評不知道該執著於理想拼命鼓吹呢? 還是順應大眾的口味，大加討伐一番。

上程式設計課程時常常提醒大家用的是 C 語言而不是 C++，就是不喜歡讓同學在使用支援物件導向的語言 (例如 C++) 以程序式的方法製作軟體時，自以為是製作物件式的軟體，運用物件式的語言並無法保證你用物件化的方式來設計、規劃及製作軟體， (另一方面，運用不支援物件導向的語言寫的軟體仍然可以基於物件導向的方法來設計，只是程式設計者所要遵循的規則無法由編譯器來幫你檢查，而必須由程式設計者自己來實現，) 學習物件導向的軟體設計方法可以讓大家領略軟體製作時工程式的嚴謹過程，了解軟體中物件系統紮實可重用的根基。

使用 VB 設計視窗環境應用程式的軟體工作者很明顯地比使用 C++/MFC 來設計視窗環境應用程式的工程師多太多了，由表象上來分析，使用者多的軟體發展環境資源多、可以諮詢的人也多，要完成計劃的阻礙比較低，當然吸引更多的人來投入。很沮喪地說，我幾乎找不到用 VB 寫不出來的視窗應用程式， (講這句話時有一點像是說沒有用 Assembly 寫不出來的程式一樣)，如果為了安慰自己而說某些系統的應用為了配合作業系統還是需要用 C/C++ 的話，那微軟還有 COM/ActiveX 的技術可以讓 VB 的應用程式設計者輕鬆地運用 C/C++ 程式設計者的產品，那為什麼要 C++/MFC??? 不會說是寫系統核心才用得到吧，那你我什麼時候才寫得到系統核心呢?

由設計軟體的方法來比較， VB 是架構在 Basic 這種型態並非非常嚴謹的程序式語言上，先天上就有容易學習的優點，製作時不需要做嚴謹的分析設計圖，撰寫程式碼時不需嚴謹地訂定界面，維護封裝，入門的門檻明顯地比 C++/物件導向的程式製作方法要低得多。由另一個角度來看，大多數人在使用 VB 來設計應用系統時應該都是由界面物件開始設計，也就是應用 VB 表單編輯器來設計人與機器間的界面，然後再應用事件驅動的視窗程式運作模型逐一填入各個界面所引發的程式動作，這是非常功能性的 top-down 程式設計， (因為用到了許多界面物件，又用到了事件驅動的概念，所以許多人覺得 VB 也是物件導向了，這是很大的誤會，大多數程式設計師在設計 VB 的程式時可能對 "快速地完成設計" 要比 "完整的分析目標系統的運作與組成" 要注重得多，物件系統中抽象化的功能物件恐怕更不是考慮的重點，沒有這些基本考量的程式決不會是物件導向的，物件導向的四大特性甚至都還沒有包含 "事件驅動" 呢。) VB 程式的設計方法可以說是由外而內的， (在設計使用者界面的雛型時相信是一個很有用的工具)，反觀使用 C++/MFC 來設計物件式系統時，通常不會由使用者界面著手，一般是由應用領域中系統運作來開始分析，所分析設計出來的物件不見得是人機界面的物件，而是運作系統中的物件，例如在進出貨管理系統中，實體貨物都有其相對應的軟體物件，儲存/載運/處理實體貨物的機制中，所有的資料、人員也都是系統中的物件，實體機制中所有的動作都在軟體系統中模擬為物件的互動，這些物件構成了軟體系統的核心機制，其中軟體物件和人員之間的界面也就是人機的界面，通常會抽離出來由使用者的角度進一步地設計合理美觀的互動機制，這種設計方式比較是由內而外的，通常可以先使核心軟體模型完全地符合應用環境來運作，然後再替這個系統架構人機間的視窗圖形化界面。

VB 自從 4.0 以後也可以自定抽象的物件了，有了封裝的特性，據說也可以繼承了，那應該也算是支援物件導向的軟體產品了，終究像 COBOL, PASCAL, FORTRAN, Perl 等等程序化的語言也都有了物件化的版本，可是相信沒有太多的程式設計師運用這些物件導向的語言功能，如果要求使用 VB 的人要先學會這些物件導向的方法，然後再來設計視窗應用程式的話，恐怕使用 VB 的人就不會比使用 C++/MFC 的人多太多了，就以微軟推出的 C# (C Sharp) 語言來說，它的目標市場恐怕和 VB 必須要有相當大的區隔。

究竟什麼時候該選擇 C++/MFC 來作為視窗環境應用程式的發展工具呢? 依照我個人的看法，應該是在你有一個嚴謹分析、設計、製作的物件導向系統之後，而你希望替它加上 "有效率" 的視窗界面的時候，才會有此選擇，為什麼會強調 "有效率" 呢? 因為在 Windows 平台上當然以 C++/MFC 來使用其 API 時能夠最直接地完成界面設計，否則如果要考慮到移植性的話， Java 恐怕會是一個非常合乎成本效益的技術平台，只要寫過一次以後，在許多的平台上都可以使用完全一樣的程式碼。另外其實要製作一個物件導向系統的時候其實也不一定要使用 C++，有許多的評論闡釋為什麼 C++ 不是一個好的物件導向語言，最主要的原因其實還是因為 C++ 包涵了 C 的所有語法，因此也一併允許程式設計者使用程序導向的方式來設計程式，如此在 C++ 語言的設計上沒有辦法儘量協助程式設計者來設計出物件導向的程式，反而暗藏很多陷阱，使得程式設計者很容易寫出違反物件導向原則的程式碼，例如指標、side effect、struct 等等不勝枚舉，反之像是 Eiffle, Java 這些語言中，就在語言的設計層面上運用一些巧思來避免使用者寫出違反物件導向的程式碼。 C++ 最大的好處就是可以編譯出很有效率的程式碼，但是這些設計通常也很容易違背物件導向的原則，通常是由有經驗的程式設計師在考慮軟體系統的擴充性、維護性、與效率之後，經過一番掙扎考量後才下的決定。一般情況下初學者很容易在考慮不周全的狀況下誤用一些語言的特性，因此嚴格來說使用 C++ 撰寫物件導向程式的門檻比起用 Java 或是用 SmallTalk, Eiffle 要來的高。

經過上面的介紹之後，其實很多人一定會問說那為什麼不由 Java 開始學起呢? 也不知道為什麼，闡釋物件導向概念的書籍大部分以 C++ 為例(真 OO無雙注：本文在2001年撰寫，早期的確以C++闡釋物件導向的書較多，但現在Java講物件導向的書也不少了)，也許因為 C++ 這種語言比較容易舉出反例，因為很容易寫出不適當的程式來吧! 另一方面，介紹 JAVA 的書籍常常把太多篇幅用來介紹 JAVA 的類別函式庫，包括 AWT, Swing, Network, IO, RMI 等等絢麗的功能，耗盡了篇幅，以致於沒有在如何正確地建構物件導向系統這樣一個重要的主題上做文章，例如說什麼樣的狀況下可以運用繼承，什麼樣的狀況下應該用群集等等。

使用 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 這樣的環境喔。