引述
VB, Delphi, BCB 和 C++/MFC 的抉擇 (上)
轉貼自 http://squall.cs.ntou.edu.tw/ (海大資工-丁培毅老師教學網站)
————————————————————————-
VB: Microsoft Visual Basic
Delphi: Objective Pascal with visualized environment by Borland International
BCB: Borland C++ Builder
MFC: Microsoft foundation class這是一個我不太喜歡談的決策問題，一直很希望由資訊系出去的學生都能夠了解製作軟體的各種方法， 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++ 語言的設計上沒有辦法儘量協助程式設計者來設計出物件導向的程式，反而暗藏很多陷阱，使得程式設計者很容易寫出違反物件導向原則
