理解面向過程（OPP）、面向對象（OOP）、面向切面（AOP）

概念

面向過程編程OPP：Procedure Oriented Programming，是一種以事物爲中心的編程思想。主要關注「怎麼作」，即完成任務的具體細節。

面向對象編程OOP：Object Oriented Programming，是一種以對象爲基礎的編程思想。主要關注「誰來作」，即完成任務的對象。

面向切面編程AOP：Aspect Oriented Programming，基於OOP延伸出來的編程思想。主要實現的目的是針對業務處理過程當中的切面進行提取，它所面對的是處理過程當中的某個步驟或階段，以得到邏輯過程當中各部分之間低耦合性的隔離效果。

每種編程思想都有各自的優勢，它們適用在不一樣的狀況下：面向過程性能很高，面向對象比較易於管理和維護，面向切面使軟件變得更靈活。

新的編程範式，並不必定徹底各方面都優於舊的編程範式，它們只是在某一特定領域或特殊場景下有着獨到的優點。

編程範式只有適合不適合項目特性，沒有絕對的好壞。

 

OPP和OOP

面向過程是最爲實際的一種思考方式，就算是面向對象的方法也是含有面向過程的思想。能夠說面向過程是一種基礎的方法。它考慮的是實際地實現。通常的面向過程是從上往下步步求精，因此面向過程最重要的是模塊化的思想方法。當程序規模不是很大時，面向過程的方法還會體現出一種優點。由於程序的流程很清楚，按着模塊與函數的方法能夠很好的組織。

面向對象是基於對象概念，以對象爲中心，以類和繼承爲構造機制，來認識、理解、刻畫客觀世界和設計、構建相應的軟件系統。類和繼承是是適應人們通常思惟方式的描述範式。方法是容許做用於該類對象上的各類操做。這種對象、類、消息和方法的程序設計範式的基本點在於對象的封裝性和類的繼承性。經過封裝能將對象的定義和對象的實現分開，經過繼承能體現類與類之間的關係，以及由此帶來的動態聯編和實體的多態性。

舉個栗子：

好比完成「吃飯」這個任務。

面向過程的寫法，須要封裝一個eat()函數：

若是是狗吃屎，則eat(狗,屎)；

若是是人吃肉，則eat(人,肉)；

eat是人和狗共用的吃飯本能。

那若是以後要處理貓吃魚、魚吃蝦、奧特曼吃小怪獸呢？eat函數中就會存在大量的if…else的判斷，這段代碼，無疑是很噁心的。

若是是面向對象思想，如何來解決這個問題呢？

咱們發現，狗、人、貓、魚、奧特曼，都有一個「吃」的共性。咱們抽象出每一個受體的類，而後繼承，這樣都具備「吃」的方法。

當咱們想要執行狗吃屎時，那就「狗->eat(屎)」，這樣，咱們從面向過程維護eat()的焦點，轉移到了面向對象維護角色的焦點上來。咱們只須要維護好不一樣的角色（類）就行了，而且狗的eat不會影響到貓的eat，貓的eat也不會影響到人的eat。

因此，oop思想很是貼近軟件工程高內聚的思想：本身管好本身的東西，本身作好本身的事情。

大多數支持面向對象的語言，同時也支持面向過程，不管是JAVA、PHP，仍是JS，它們都還沒法徹底面向對象，由於面向過程是必然的，面向過程表明着必要的程序流程，調動對象進行組合或對象內部能力的實現，都必定會存在「過程」，它最終仍是須要經過拆分步驟來指導最具體的執行細節。

在此，咱們也能獲得一些感悟，許多事情並不是徹底非黑即白，非OOP就必然是OPP，特別是思想層面的東西，它們呈現出互相結合的形態，從OPP到OOP，這是一個思想進步的過程。

 

AOP

面向切面編程主要實現的目的是針對業務處理過程當中的切面進行提取，它所面對的是處理過程當中的某個步驟或階段，以得到邏輯過程當中各部分之間低耦合性的隔離效果。

那麼，AOP如何體現？

這裏能夠聯想一下laravel的中間件、javaweb的攔截器、vue的Decorator…它們都是AOP思想的實踐。裝飾器模式、代理模式，它們也是基於AOP思想的設計模式。

AOP思想，指導咱們經過找到平整切面的形式，插入新的代碼，使新插入的代碼對切面上下原有流程的傷害降到最低。

舉個栗子：

咱們拿laravel中間件作什麼？

權限、日誌、請求過濾、請求頻率限制、csrf過濾……

咱們知道，中間件對於controller的業務邏輯，不會有任何傷害。

若是沒有這個切面，咱們想要記錄請求日誌，可能須要在每一個controller的具體方法中寫日誌記錄的代碼，或者調用日誌記錄的函數、方法。

這會使一段記錄日誌的代碼，或調用記錄日誌的調用語句出如今許多controller中，這與controller本來要關注的邏輯無關，使controller職責不單一，提升維護成本。

固然，咱們可能會寫一個父類，讓許多controller來繼承這個父類，而後統一在父類的__construct方法中記錄日誌，以此來解決耦合問題。

但實際上，這個父類的construct方法，不正是一個切面嗎？它在原有流程中截取了一個切面，在切面中植入代碼，以達到承上啓下的做用，而且不對上下文產生傷害。

從這個例子中，咱們也能得出另一個思考：AOP指導咱們尋找切面，但找到合適的切面，也尤其重要。就像上文，父類構造函數的切面和中間件的切面比起來，顯然中間件這個切面更利於維護，你能夠靈活選擇中間件，但你沒法靈活選擇父類，由於決定你的controller繼承什麼父類的，不是切面中的代碼，而是controller自己處理什麼邏輯。

許多項目，OPP、OOP、AOP是同時存在的，它們是編程範式，是一種指導編程的思想，並不是不能互相配合。

本文從宏觀角度講解三種編程思想的異同點，旨在引領你們打個樣。具體到每一個編程思想，其實還有不少深究的點，好比AOP思想，貫穿在不少設計模式中，好比代理模式、裝飾器模式、職責鏈模式……；學無止境啊，天天成長一點，終究不會錯的。