? ? ?專業術語晦澀難懂，特別是當你沒有寫過稍微大點的系統的時候，你要理解這里面的區別很難。

?????? 從最簡單的早期我們學習開始，我們除了練習hello world掌握了入門函數之后，基本都再練習算法。比如水仙花數的獲取，冒泡排序，碾轉相除法的算法題目，這個時候我們用面向對象來思考，沒有太多意義，因為他單純的只是要解決某個具體的算數層面復雜點。我們大部分情況下，需要的都是推理和算法能力，所以當我們想懂了怎么實現的時候，立刻寫幾行代碼，然后開始run模式，就可以知道我們的想法對了沒對。

? 更復雜點的工程算法，比如抽獎函數的設計（需要考慮到不同獎品出現不同的概率，而且將不同概率輸入該功能函數之后，會返回我們本次的抽獎結果編號），又或者是菜單列表的獲取，需要用到遞歸，讀取每個欄目下級的子欄目，同時將這個結果返回給上級結果（遞歸概念，分類里面最常用的算法），讀取文本里面的N行內容，分析提取我們需要的行（簡單清洗數據的邏輯）。基本上基礎的開發，這些簡單算法堆積的時候，發現面向對象毫無優勢，甚至是劣勢，我為了解答某個題目，腦子里可能出現了N個算法，但是不知道對錯，快速寫代碼跑，直接寫肯定比邊寫還邊組織結構要快很多。而且在接入入門早期的時候，我們更傾向于快速實現效果給其他人看，也就是做一個demo的展示產品，這個時候，更快是我們的目標，而對象天然的就增加了這層思考的復雜度。

? 于是我們開始操作真正的項目，在真正的項目里面，邏輯鏈條和關系復雜度比之前的組織幾個函數方法完全不同概念，在絕大部分的項目里面，不是算法工程師的話，基本極少用到獨自創新的算法，這個時候的工作面臨的是無數個模塊和函數代碼，怎么拼接整理到一起。
最簡單的電商產品下單邏輯，我們用流程化的方法來寫這個功能。思考的流程是這樣的: 我們寫個函數

檢查商品ID——去數據庫查詢產品——查詢是否下架——查詢庫存——查詢商品其他關聯信息——驗證登錄的用戶身份——檢查用戶——檢查用戶購買的數量信息——檢查用戶下單的合法性——.檢查優惠券的合法性——計算當前的訂單價格——計算訂單價格扣除優惠券的計算方法——下單——鎖定住優惠券——….

我們將這個流程從頭到尾，每一步都實現在一個大型的函數方法里面，洋洋灑灑寫了幾百行，終于心滿意足的感覺完成了這個大型功能。這個時候，需求改了，用戶鑒權信息的種類有變更，第二個優惠券可能有很多種，需要重新去N個表里面查詢不同的優惠券。過了一陣子，你回頭來修改代碼，你發現自己密密麻麻的寫了一本天書，中間某個地方錯誤了，你發現不了問題，需要從頭到尾一步一步斷點打印，而且幾乎沒有辦法的去完善系統。因為出一點問題，要查看自己的一整片代碼。

洋洋灑灑寫個上幾百行代碼，封裝到一個函數，直接實現了對應功能，感覺上很方便，沒有其他的干擾，但是在維護和調試的時候，基本都是癱瘓掉。實在是改不動，如果再碰上別人的代碼也是這種風格，邏輯復雜度又很深，基本上就是提桶跑路。接觸的幾個改不下去的項目，基本都是這種風格，洋洋灑灑，代碼堆積在一個方法里面，然后開發不下去了，直接提桶跑路，留給后面的人修改一地雞毛。這是很典型的面向過程開發者思維，就是以完成過程和實現為核心目標，不考慮后續維護和拓展的開發模式。如果不是刻意去學習對象開發方法，大部分人的第一開發定勢都是過程化開發。

而如果是面向對象開始開發，首先我們可以嘗試著將上述流程進行對象化處理—— 產品對象，用戶對象，優惠券 。
我們使用產品對象的獲取方法獲取產品（獲取失敗就退出，那是產品對象出問題了）
同樣獲取用戶對象方法（信息，權限，金額檢測）同樣失敗，退出

優惠券對象方法（檢測優惠券的相關信息）

這樣我不能再按照之前的的流程化邏輯實現我要的功能，而是設計好一個一個對象，然后我用我的總對象去調用各個對象里面的方法，如果某塊出現了問題，我只要直接去調試對應的對象模塊即可。

從這里可以很明顯的看出倆者的特征，當項目的規模比較小的時候，過程化開發更有優勢，因為快速。而面向對象需要不斷設計對應的對象，還要梳理結構。

反過來，當項目越來越大的時候，模塊不斷交叉，對象方法復用度也大幅度提升，對象化開發方法優勢非常明顯。

而考慮到當前的主要項目，其實一般都是第一期簡單，如果有二三四期開發工程的情況，如果你為了快速完成一期使用了過程化開發方法，后面會非常痛苦來調整，所以在一般情況下，大部分項目（除了極少部分你確定知道規模很小的項目）默認采用對象化開發方法，為后期拓展性奠定比較好的基礎。