面相物件和麵向過程的區別
阿新 • • 發佈：2019-01-03
(1)借用一本書裡的比喻
寫程式就好像是在看電視
用面向過程就等於是要先自己製造一臺電視，然後再收看節目；
而面向物件則是直接去商店買一臺電視收看。
面向物件程式設計省去了很多不需要知道的部分，就好比即使你不清楚如何製造電視機，也能看電視一樣。
(2)
面向物件的資料是封裝在物件內部，而面向過程的則不是。
面向物件的概念更能描述現實世界，任何物體都是物件，而面向過程則比較麻煩。當然，如果你先學了面向過程，反而會覺得面向物件更為抽象。
從現在的主流和大型開發方面來說，面向物件比較多。
(3)
兩種方法都是程式設計中的比較常用的方法，從理論上來說，都能達到用計算機程式來解決實際問題的目的，
只不過是其中所體現出來的思想不一樣而已。
面向過程：面向過程的思想是把一個專案、一件事情按照一定的順序，從頭到尾一步一步地做下去，先做什麼，後做什麼，一直到結束。這種思想比較好理解，其實這也是一個人做事的方法。
面向物件：面向物件的思想是把一個專案、一件事情分成更小的專案，或者說分成一個個更小的部分，每一部分負責什麼方面的功能，最後再由這些部分組合而成為一個整體。這種思想比較適合多人的分工合作，就像一個大的機關，分成各個部門，每個部門分別負責某樣職能，各個部門可以充分發揮自己的特色，只要符合一定前提就行了。
舉例說明1：比如剛才說的一個大的機關，要做某一個專案，從面向過程的思想來說，應該是這樣分析的，先怎麼樣，再怎麼樣，最後怎麼樣。第一樣應該如何完成，第二樣應該如何完成等等。等到每一步驟都完成，專案也就完成了。而面向物件的思想則應該是這樣想的，這個專案是由幾個部分組成的，我們就做好分工，成立一個部門來做一個部分的功能，另一個部門來做另一個部分。各個部門可以不用理解其他部門的事，只要完成自己那一部分的事情就OK了。
舉例說明2：又比如我們有一臺演出，為簡單起見，假設有如下流程：主持人開場——演員一表演——演員二表演——主持人總結。用面向過程的思想來分析，就是先完成主持人開場，再完成演員一的表演，再完成演員二的表演，最後完成主持人的總結。而如果用面向物件的思想來分析，就應該是這樣的。這個演出由兩大部分組成：主持人、演員。與主持人相關的：開場、總結。與演員相關的：演員編號、所演的節目。然後這臺演出就可以這樣策劃：需要一個主持人a，需要兩個演員b、c。演出的事情可以表示為：a的開場——b、c的編號和節目——a的總結。
(4)
面向過程就是分析出解決問題所需要的步驟，然後用函式把這些步驟一步一步實現，使用的時候一個一個依次呼叫就可以了。
面向物件是把構成問題事務分解成各個物件，建立物件的目的不是為了完成一個步驟，而是為了描敘某個事物在整個解決問題的步驟中的行為。
例如五子棋，面向過程的設計思路就是首先分析問題的步驟：1、開始遊戲，2、黑子先走，3、繪製畫面，4、判斷輸贏，5、輪到白子，6、繪製畫面，7、判斷輸贏，8、返回步驟2，9、輸出最後結果。把上面每個步驟用分別的函式來實現，問題就解決了。
而面向物件的設計則是從另外的思路來解決問題。整個五子棋可以分為 1、黑白雙方，這兩方的行為是一模一樣的，2、棋盤系統，負責繪製畫面，3、規則系統，負責判定諸如犯規、輸贏等。第一類物件（玩家物件）負責接受使用者輸入，並告知第二類物件（棋盤物件）棋子佈局的變化，棋盤物件接收到了棋子的i變化就要負責在螢幕上面顯示出這種變化，同時利用第三類物件（規則系統）來對棋局進行判定。
可以明顯地看出，面向物件是以功能來劃分問題，而不是步驟。同樣是繪製棋局，這樣的行為在面向過程的設計中分散在了總多步驟中，很可能出現不同的繪製版本，因為通常設計人員會考慮到實際情況進行各種各樣的簡化。而面向物件的設計中，繪圖只可能在棋盤物件中出現，從而保證了繪圖的統一。
功能上的統一保證了面向物件設計的可擴充套件性。比如我要加入悔棋的功能，如果要改動面向過程的設計，那麼從輸入到判斷到顯示這一連串的步驟都要改動，甚至步驟之間的循序都要進行大規模調整。如果是面向物件的話，只用改動棋盤物件就行了，棋盤系統儲存了黑白雙方的棋譜，簡單回溯就可以了，而顯示和規則判斷則不用顧及，同時整個對物件功能的呼叫順序都沒有變化，改動只是區域性的。
再比如我要把這個五子棋遊戲改為圍棋遊戲，如果你是面向過程設計，那麼五子棋的規則就分佈在了你的程式的每一個角落，要改動還不如重寫。但是如果你當初就是面向物件的設計，那麼你只用改動規則物件就可以了，五子棋和圍棋的區別不就是規則嗎？（當然棋盤大小好像也不一樣，但是你會覺得這是一個難題嗎？直接在棋盤物件中進行一番小改動就可以了。）而下棋的大致步驟從面向物件的角度來看沒有任何變化。
當然，要達到改動只是區域性的需要設計的人有足夠的經驗，使用物件不能保證你的程式就是面向物件，初學者或者很蹩腳的程式設計師很可能以面向物件之虛而行面向過程之實，這樣設計出來的所謂面向物件的程式很難有良好的可移植性和可擴充套件性。
寫程式就好像是在看電視
用面向過程就等於是要先自己製造一臺電視，然後再收看節目；
而面向物件則是直接去商店買一臺電視收看。
面向物件程式設計省去了很多不需要知道的部分，就好比即使你不清楚如何製造電視機，也能看電視一樣。
(2)
面向物件的資料是封裝在物件內部，而面向過程的則不是。
面向物件的概念更能描述現實世界，任何物體都是物件，而面向過程則比較麻煩。當然，如果你先學了面向過程，反而會覺得面向物件更為抽象。
從現在的主流和大型開發方面來說，面向物件比較多。
(3)
兩種方法都是程式設計中的比較常用的方法，從理論上來說，都能達到用計算機程式來解決實際問題的目的，
只不過是其中所體現出來的思想不一樣而已。
面向過程：面向過程的思想是把一個專案、一件事情按照一定的順序，從頭到尾一步一步地做下去，先做什麼，後做什麼，一直到結束。這種思想比較好理解，其實這也是一個人做事的方法。
面向物件：面向物件的思想是把一個專案、一件事情分成更小的專案，或者說分成一個個更小的部分，每一部分負責什麼方面的功能，最後再由這些部分組合而成為一個整體。這種思想比較適合多人的分工合作，就像一個大的機關，分成各個部門，每個部門分別負責某樣職能，各個部門可以充分發揮自己的特色，只要符合一定前提就行了。
舉例說明1：比如剛才說的一個大的機關，要做某一個專案，從面向過程的思想來說，應該是這樣分析的，先怎麼樣，再怎麼樣，最後怎麼樣。第一樣應該如何完成，第二樣應該如何完成等等。等到每一步驟都完成，專案也就完成了。而面向物件的思想則應該是這樣想的，這個專案是由幾個部分組成的，我們就做好分工，成立一個部門來做一個部分的功能，另一個部門來做另一個部分。各個部門可以不用理解其他部門的事，只要完成自己那一部分的事情就OK了。
舉例說明2：又比如我們有一臺演出，為簡單起見，假設有如下流程：主持人開場——演員一表演——演員二表演——主持人總結。用面向過程的思想來分析，就是先完成主持人開場，再完成演員一的表演，再完成演員二的表演，最後完成主持人的總結。而如果用面向物件的思想來分析，就應該是這樣的。這個演出由兩大部分組成：主持人、演員。與主持人相關的：開場、總結。與演員相關的：演員編號、所演的節目。然後這臺演出就可以這樣策劃：需要一個主持人a，需要兩個演員b、c。演出的事情可以表示為：a的開場——b、c的編號和節目——a的總結。
(4)
面向過程就是分析出解決問題所需要的步驟，然後用函式把這些步驟一步一步實現，使用的時候一個一個依次呼叫就可以了。
面向物件是把構成問題事務分解成各個物件，建立物件的目的不是為了完成一個步驟，而是為了描敘某個事物在整個解決問題的步驟中的行為。
例如五子棋，面向過程的設計思路就是首先分析問題的步驟：1、開始遊戲，2、黑子先走，3、繪製畫面，4、判斷輸贏，5、輪到白子，6、繪製畫面，7、判斷輸贏，8、返回步驟2，9、輸出最後結果。把上面每個步驟用分別的函式來實現，問題就解決了。
而面向物件的設計則是從另外的思路來解決問題。整個五子棋可以分為 1、黑白雙方，這兩方的行為是一模一樣的，2、棋盤系統，負責繪製畫面，3、規則系統，負責判定諸如犯規、輸贏等。第一類物件（玩家物件）負責接受使用者輸入，並告知第二類物件（棋盤物件）棋子佈局的變化，棋盤物件接收到了棋子的i變化就要負責在螢幕上面顯示出這種變化，同時利用第三類物件（規則系統）來對棋局進行判定。
可以明顯地看出，面向物件是以功能來劃分問題，而不是步驟。同樣是繪製棋局，這樣的行為在面向過程的設計中分散在了總多步驟中，很可能出現不同的繪製版本，因為通常設計人員會考慮到實際情況進行各種各樣的簡化。而面向物件的設計中，繪圖只可能在棋盤物件中出現，從而保證了繪圖的統一。
功能上的統一保證了面向物件設計的可擴充套件性。比如我要加入悔棋的功能，如果要改動面向過程的設計，那麼從輸入到判斷到顯示這一連串的步驟都要改動，甚至步驟之間的循序都要進行大規模調整。如果是面向物件的話，只用改動棋盤物件就行了，棋盤系統儲存了黑白雙方的棋譜，簡單回溯就可以了，而顯示和規則判斷則不用顧及，同時整個對物件功能的呼叫順序都沒有變化，改動只是區域性的。
再比如我要把這個五子棋遊戲改為圍棋遊戲，如果你是面向過程設計，那麼五子棋的規則就分佈在了你的程式的每一個角落，要改動還不如重寫。但是如果你當初就是面向物件的設計，那麼你只用改動規則物件就可以了，五子棋和圍棋的區別不就是規則嗎？（當然棋盤大小好像也不一樣，但是你會覺得這是一個難題嗎？直接在棋盤物件中進行一番小改動就可以了。）而下棋的大致步驟從面向物件的角度來看沒有任何變化。
當然，要達到改動只是區域性的需要設計的人有足夠的經驗，使用物件不能保證你的程式就是面向物件，初學者或者很蹩腳的程式設計師很可能以面向物件之虛而行面向過程之實，這樣設計出來的所謂面向物件的程式很難有良好的可移植性和可擴充套件性。