面向對象面向過程

一、面向語句：

直接寫原生的sql語句，可是這樣代碼不容易維護。改一個方法會致使整個項目都要改動，

二、面向過程

   定義一些函數，用的時候就調用不用就不調用。可是這也有解決不了的問題，若是要維護須要改動代碼，有可能也會致使整個項目的改動

三、面向對象：封裝  繼承  多態

  定義一個類，這個類要遵循職責單一，就是說一個類只有一個職責。且這個類是不能改動的，若是想要添加東西只能是繼承這個類而後在擴展，

 

面向過程就是分析出解決問題所須要的步驟，而後用函數把這些步驟一步一步實現，使用的時候一個一個依次調用就能夠了。

面向對象是把構成問題事務分解成各個對象，創建對象的目的不是爲了完成一個步驟，而是爲了描敘某個事物在整個解決問題的步驟中的行爲。

例如五子棋，面向過程的設計思路就是首先分析問題的步驟：一、開始遊戲，二、黑子先走，三、繪製畫面，四、判斷輸贏，五、輪到白子，六、繪製畫面，七、判斷輸贏，

八、返回步驟2，九、輸出最後結果。把上面每一個步驟用分別的函數來實現，問題就解決了。

 

而面向對象的設計則是從另外的思路來解決問題。整個五子棋能夠分爲 一、黑白雙方，這兩方的行爲是如出一轍的，二、棋盤系統，負責繪製畫面，三、規則系統，

負責斷定諸如犯規、輸贏等。第一類對象（玩家對象）負責接受用戶輸入，並告知第二類對象（棋盤對象）棋子佈局的變化，

棋盤對象接收到了棋子的i變化就要負責在屏幕上面顯示出這種變化，同時利用第三類對象（規則系統）來對棋局進行斷定。

 

能夠明顯地看出，面向對象是以功能來劃分問題，而不是步驟。一樣是繪製棋局，這樣的行爲在面向過程的設計中分散在了總多步驟中，

極可能出現不一樣的繪製版本，由於一般設計人員會考慮到實際狀況進行各類各樣的簡化。而面向對象的設計中，繪圖只可能在棋盤對象中出現，

從而保證了繪圖的統一。

 

功能上的統一保證了面向對象設計的可擴展性。好比我要加入悔棋的功能，若是要改動面向過程的設計，那麼從輸入到判斷到顯示這一連串的步驟都要改動，

甚至步驟之間的循序都要進行大規模調整。若是是面向對象的話，只用改動棋盤對象就好了，棋盤系統保存了黑白雙方的棋譜，簡單回溯就能夠了，

而顯示和規則判斷則不用顧及，同時整個對對象功能的調用順序都沒有變化，改動只是局部的。

 

再好比我要把這個五子棋遊戲改成圍棋遊戲，若是你是面向過程設計，那麼五子棋的規則就分佈在了你的程序的每個角落，

要改動還不如重寫。可是若是你當初就是面向對象的設計，那麼你只用改動規則對象就能夠了，五子棋和圍棋的區別不就是規則嗎？

（固然棋盤大小好像也不同，可是你會以爲這是一個難題嗎？直接在棋盤對象中進行一番小改動就能夠了。）

而下棋的大體步驟從面向對象的角度來看沒有任何變化。

 

固然，要達到改動只是局部的須要設計的人有足夠的經驗，使用對象不能保證你的程序就是面向對象，

初學者或者很蹩腳的程序員極可能以面向對象之虛而行面向過程之實，這樣設計出來的所謂面向對象的程序很難有良好的可移植性和可擴展性。