物件導向程式設計OOP (Object-Oriented Programming) 是一種近幾年來程式設計的新觀念，它將程式語言要處理的對象看成是一種物件，傳統程式設計以程序導向 (procedure-oriented) 為主，程式的動作過程就好像是電腦執行程式的流程一樣，但是這樣卻和實際上要解決的問題無法緊密結合。
物件導向的程式設計方法，是站在較人性化的觀點來思考、設計程式的邏輯，例如在傳統的程式設計語言中，我們要開啟一個資料庫檔案，通常是撰寫如下列的程式呼叫：『開啟檔案(資料庫)』，而在物件導向語言當中，則是執行下列的程式呼叫：『資料庫.開啟檔案』。
這只是物件導向的一種特性，此外，它還擴充了一般程式語言的功能，例如在C++ 語言當中，我們可定義許多相同名稱的副程式，它們各自執行不同的功能，而不會互相衝突──因為它們是針對不同的物件運作的，這是物件導向當中的『多形』(polymorphism)，其它重要的概念還有『封裝』 (encapsulation) 與『繼承』(inheritance)，使得程式撰寫可更容易模組化 (modular)，也更易於重複使用 (reuse) 軟體元件。一般說來，SmallTalk與Simula兩種程式語言是OOP的始祖，C++、Java、Javascript、Flash Action Script與C# 則是近來OOP的主流。
在現實面上，程序導向和物件導向算是比較一般化的，其中程序導向語言製作的軟體仍然佔有最大的應用市場，也許程序式的運作模型最能被大家接受，最容易隨性地發揮，與現今 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 來設計物件式系統時，通常不會由使用者界面著手，一般是由應用領域中系統運作來開始分析，所分析設計出來的物件不見得是人機界面的物件，而是運作系統中的物件，例如在進出貨管理系統中，實體貨物都有其相對應的軟體物件，儲存/載運/處理實體貨物的機制中，所有的資料、人員也都是系統中的物件，實體機制中所有的動作都在軟體系統中模擬為物件的互動，這些物件構成了軟體系統的核心機制，其中軟體物件和人員之間的界面也就是人機的界面，通常會抽離出來由使用者的角度進一步地設計合理美觀的互動機制，這種設計方式比較是由內而外的，通常可以先使核心軟體模型完全地符合應用環境來運作，然後再替這個系統架構人機間的視窗圖形化界面。
沒有留言:
張貼留言