面向過程編程(OPP) 和面向對象編程(OOP)的關系

原文鏈接：http://blog.csdn.net/phphot/article/details/3985480

關於面向過程的編程(OPP)和面向對象的編程(OOP),給出這它們的定義的人很多，您可以從任何資料中找到很專業的解釋，但以我的經驗來看，講的相對枯燥一點，不是很直觀。除非您已經有了相當的積累，否則說起來還是比較費勁。

我是個老程序員出身，雖然現在的日常工作更多傾向了管理，但至今依然保持編碼的習慣，這句話什麽意思呢？我跟大家溝通應該沒有問題。無論你是在重復 我走過的路，或者已經走在了我的前面，大家都會有那麽一段相同的經歷，都會在思想層面上有一種理解和默契，所以我還是會盡量按照大多數人的常規思維寫下 去。

面向過程的編程(OPP)產生在前，面向對象的編程(OOP)產生在後，所以面向對象的編程(OOP)一定會繼承前者的一些優點，並摒棄前者存在的 一些缺點，這是符合人類進步的自然規律。兩者在各自的發展和演變過程中，一定會相互借鑒，相互融合，吸收對方的優點，從而出現某些方面的趨同性。但是，即 使兩者有更多的相似點，也不會改變它們本質上的不同，因為它們的出發點不同，完全是兩種截然不同的思維方式。關於兩者的關系，我的觀點是這樣的：面向對象 編程(OOP)在局部上一定是面向過程(OP)的，面向過程的編程(OPP)在整體上應該借鑒面向對象(OO)的思想。這一段說的的確很空洞，而且也一定 會有引來爭議，不過，我勸您還是在閱讀了後面的內容之後，再來評判我觀點的正確與否。

象C++、C#、Java等都是面向對象的語言，c,PHP(暫且這麽說，因為php4以後就支持OO)都是面向過程的語言，那麽是不是我用C++ 寫的程序一定就是面向對象，用c寫的程序一定就是面向過程呢？這種觀點顯然是沒有真正吃透兩者的區別。語言永遠是一種工具，前輩們每創造出來的一種語言， 都是你用來實現想法的利器。我覺得好多人用C#,Java寫出來的代碼，要是仔細看看，那實際就是用面向對象(OO)的語言寫的面向過程(OP)的程序。

所以，即使給關羽一根木棍，給你一桿青龍偃月刀，他照樣可以打得你滿頭是包。你就是扛著個偃月刀，也成不了關羽，因為你缺乏關羽最本質的東西---絕世武功。同樣的道理，如果你沒有領會OO思想，怎麽可能寫得出真正的OO程序呢？

那是不是面向過程就不好，也沒有存在的必要了？我從來沒有這樣說過。事實上，面向過程的編程(OPP)已經存在了幾十年了，現在依然有很多人在使 用。它的優點就是邏輯不復雜的情況下很容易理解，而且運行效率遠高於面向對象（OO）編寫的程序。所以，系統級的應用或準實時系統中，依然采用面向過程的 編程(OPP)。當然，很多編程高手以及大師級的人物，他們由於對於系統整體的掌控能力很強，也喜歡使用面向過程的編程(OPP)，比如像 Apache,QMail,PostFix,ICE等等這些比較經典的系統都是OPP的產物。象php這些腳本語言，主要用於web開發，對於一些業務邏 輯相對簡單的系統，也常使用面向過程的編程(OPP)，這也是php無法跨入到企業級應用開發的原因之一，不過php5目前已經能夠很好的支持OO了。

2.4 詳解面向過程的編程(OPP)

在面向對象出現之前，我們采用的開發方法都是面向過程的編程(OPP)。面向過程的編程中最常用的一個分析方法是“功能分解”。我們會把用戶需求先分解成 模塊，然後把模塊分解成大的功能，再把大的功能分解成小的功能，整個需求就是按照這樣的方式，最終分解成一個一個的函數。這種解決問題的方式稱為“自頂向 下”，原則是“先整體後局部”，“先大後小”，也有人喜歡使用“自下向上”的分析方式，先解決局部難點，逐步擴大開來，最後組合出來整個程序。其實，這兩 種方式殊路同歸，最終都能解決問題，但一般情況下采用“自頂向下”的方式還是較為常見，因為這種方式最容易看清問題的本質。

我舉個例子來說明面向過程的編程方式:

用戶需求：老板讓我寫個通用計算器。

最終用戶就是老板，我作為程序員，任務就是寫一個計算器程序。OK，很簡單，以下就是用C語言完成的計算器：

假定程序的文件名為：main.c。

int main(int argc, char *argv[]){

//變量初始化
int nNum1,nNum2;
char cOpr;
int nResult;
nNum1 = nNum2 = 0;
cOpr = 0;
nResult = 0;

//輸入數據
printf("Please input the first number:/r/n");
scanf("%d",&nNum1);
printf("Please input the operator:/r/n");
scanf("%s",&cOpr);
printf("Please input the second number:/r/n");
scanf("%d",&nNum2);

//計算結果
if( cOpr == ‘+‘ ){
nResult = nNum1 + nNum2;
}else if( cOpr == ‘-‘ ){
nResult = nNum1 - nNum2;
}else{
printf("Unknown operator!");
return -1;
}

//輸出結果
printf("The result is %d!",nResult);
return 0;
}

拋開細節不講，我想大多數人差不多都會這麽實現吧，很清晰，很簡單，充分體現了“簡單就是美”的原則，面向過程的編程就是這樣有條理的按照順序來逐步實現用戶需求。

凡是做過程序的人都知道，用戶需求從來都不會是穩定的，最多只能夠做到“相對穩定”。用戶可能會隨時提出加個功能，減個功能的要求，也可能會要求改 動一下流程，程序員最煩的就是頻繁地變動需求，尤其是程序已經寫了大半了，但這種情況是永遠無法避免的，也不能完全歸罪到客戶或者需求分析師。

以我們上面的代碼為例，用戶可能會提出類似的要求：
首先，你程序中實現了“加法”和“減法”，我還想讓它也能計算“乘法”、“除法”。
其次，你現在的人機界面太簡單了，我還想要個Windows計算器的界面或者Mac計算器的界面。

用戶需求開始多了，我得琢磨琢磨該如何去寫這段代碼了。我今天加了“乘”“除”的運算，明天保不齊又得讓我加個“平方”、“立方”的運算，這要是把 所有的運算都窮盡了，怎麽也得寫個千八百行代碼吧。還有，用戶要求界面能夠更換，還得寫一大堆界面生成的代碼，又得來個千八百行。以後，這麽多代碼堆在一 起，怎麽去維護，找個變量得半天，看懂了代碼得半天，萬一不小心改錯了，還得調半天。另外，界面設計我也不擅長，得找個更專業的人來做，做完了之後再加進 來吧。這個過程也就是“軟件危機”產生的過程。伴隨著軟件廣泛地應用於各個領域，軟件開發的規模變得越來越大，復雜度越來越高，而其用戶的需求越來越不穩 定。

根據用戶提出的兩個需求，面向過程的編程該如何去應對呢？我想大家都很清楚怎麽去改。Very easy，把“計算”和“界面”分開做成兩個獨立的函數，封裝到不同的文件中。
假定程序的文件名為：main.c。

#include "interface.h"
#include "calculate.h"
int main(int argc, char *argv[]){

//變量初始化
int nNum1,nNum2;
char cOpr;
int nResult;
nNum1 = nNum2 = 0;
cOpr = 0;
nResult = 0;

//輸入數據
if( getParameters(&nNum1,&nNum2,&cOpr) == -1 )
return -1;

//計算結果
if( calcMachine(nNum1,nNum2,cOpr,&nResult) == -1 )
return -1;

//輸出結果
printf("The result is %d!",nResult);

return 0;
}

interface.h:
int getParameters(int *nNum1,int * nNum2,char *cOpr);

interface.c:
int getParameters(int *nNum1,int * nNum2,char *cOpr){
printf("Please input the first number:/r/n");
scanf("%d",nNum1);
printf("Please input the operator:/r/n");
scanf("%s",cOpr);
printf("Please input the second number:/r/n");
scanf("%d",nNum2);

return 0;
}

calculate.h:
int calcMachine(int nNum1,int nNum2,char cOpr, int *nResult);

calculate.c:
int calcMachine(int nNum1,int nNum2,char cOpr,int *nResult){
if( cOpr == ‘+‘ ){
*nResult = nNum1 + nNum2;
}else if( cOpr == ‘-‘ ){
*nResult = nNum1 - nNum2;
}else{
printf("Unknown operator!");
return -1;
};
return 0;
}

“計算”和“界面”分開之後，添加新功能或者修改bug就方便多了，遇到與“計算”相關的需求就去修改calculate模塊，遇到與“界面”相關的需求就去修改interface模塊，因此，整個系統模塊之間的“耦合度”就被放松了，可維護性有了一定程度的改善。

面向過程的編程(OPP)就是將用戶需求進行“功能分解”。把用戶需求先分解成模塊(.h,.c)，再把模塊(.h,.c)分解成大的功能(function)，然後把大的功能(function)分解成小的功能(function)，如此類推。

功能分解是一項很有技術含量的工作，它不僅需要分解者具有豐富的實戰經驗，而且需要科學的理論作為指導。如何分解，分解原則是什麽，模塊粒度多大合適？這些都是架構師的要考慮的問題，也是我們後面要著重講的內容。

面向過程的編程(OPP)優點是程序順序執行，流程清晰明了。它的缺點是主控程序承擔了太多的任務，各個模塊都需要主控程序進行控制和調度，主控和模塊之間的承擔的任務不均衡。
有的人把面向過程定義為：算法 + 數據結構，我覺得也很準確。面向過程的編程中算法是核心，數據處於從屬地位，數據隨算法而流動。所以采用面向過程的方式進行編程，一般在動手之前，都要編寫一份流程圖或是數據流圖。

面向過程編程(OPP) 和面向對象編程(OOP)的關系