前言
不知道大家有沒有想過功能的疊代速度和可維護性，在寫程式碼的時候總感覺有些東西一樣，所以一直在思考怎麼樣提高工作效率,直到了解到AOP後有了新的認識。
思考
當你收到上級給的一個任務讓你開發一個註冊送積分的功能，你一口氣順著邏輯寫了三天成功，過了半個月又要求在註冊送錢送優惠劵，你又在原有的基礎上花了一週勉強寫了出來，一個月後上級要你在複雜度極高的訂單模組增加跟註冊一樣的贈送邏輯，請問你該怎麼辦呢？一般的做法就是改造每個業務模組，這樣勢必把程式碼弄得一團糟，而且以後再擴充套件還是更亂，高階一點用物件導向思想就是搞出來一個超級複雜的抽象基類，用於相容兩個地方的呼叫，問下自己，這個基類是否真的做到了解耦？？？還是說對於下個接手的人來說是個巨坑。
什麼是AOP
百度的解析：
“面向切面程式設計”,這樣的名字並不是非常容易理解，且容易產生一些誤導。有些人認為“OOP/OOD11即將落伍，AOP是新一代軟體開發方式”。顯然，發言者並沒有理解AOP的含義。Aspect，的確是“方面”的意思。不過，漢語傳統語義中的“方面”，大多數情況下指的是一件事情的不同維度、或者說不同角度上的特性，比如我們常說：“這件事情要從幾個方面來看待”，往往意思是：需要從不同的角度來看待同一個事物。這裡的“方面”，指的是事物的外在特性在不同觀察角度下的體現。而在AOP中，Aspect的含義，可能更多的理解為“切面”比較合適。
可以通過預編譯方式和執行期動態代理實現在不修改原始碼的情況下給程式動態統一新增功能的一種技術。AOP實際是GoF設計模式的延續，設計模式孜孜不倦追求的是呼叫者和被呼叫者之間的解耦,提高程式碼的靈活性和可擴充套件性，AOP可以說也是這種目標的一種實現。
個人理解：
AOP比較常用在JAVA中的Spring框架，近些年php裡swoole類框架也有引入，但AOP只是一種思想，不是一種具體的技術，在這說一個我對AOP的簡單理解，我們可以把切面理解為一個點，每個點只做一件事，點與點之前沒有任何關係，然後把程式理解為一個順序的執行過程，動態地將點切入到執行過程中指定位置上的程式設計思想就是面向切面的程式設計了。
面向切面、物件導向雖然非常類似，但卻是面向不同領域的兩種設計思想。物件導向針對業務處理過程的實體及其屬性和行為進行抽象封裝，以獲得更加清晰高效的邏輯單元劃分。面向切面則是針對業務處理過程中的切面進行提取，它所面對的是處理過程中的某個步驟或階段，按點來切面。
借用一個我公司大老的圖給大家理解一下
AOP在JAVA和Swoole框架中都有很好的原生支援，不過在laravel中可以用路由中介軟體、事件等方式去實現點的觸發來實現AOP
總結
在看了我寫的這一大堆文字後，如果沒有看懂也不要緊，就如眾多的設計模式一樣，可能到了某一時刻你就像如來一樣在菩提樹下頓悟了。
本作品採用《CC 協議》，轉載必須註明作者和本文連結