AOP是一個(gè)什么概念呢？
AOP是Aspect Oriented Programming的縮寫，翻譯成中文就是面向方面編程。它是最近幾年流行起來的另一種編程方式。
- 首先，AOP只是OOP的補(bǔ)充，換句話說，Procedure Oriented Programming的工程是很難，也是幾乎不可能使用AOP的。
- 其次，AOP是對OOP系統(tǒng)的縱向切割，從另一個(gè)方面上實(shí)現(xiàn)了系統(tǒng)解耦
- 再次，AOP給OOP提供了另一種重用的可能。
對于OOP系統(tǒng)而言，系統(tǒng)的解耦主要依賴分層和良好的設(shè)計(jì)，一般良好的OOP架構(gòu)沒有不采用分層和設(shè)計(jì)模式的（當(dāng)然，分層分得恰當(dāng)不恰當(dāng)、模式用得好不好，跟框架的設(shè)計(jì)者有著直接的關(guān)系）。但是，對于OOP系統(tǒng)而言，它只能到達(dá)這一步了。
對于系統(tǒng)的必須要求，比如日志、錯(cuò)誤跟蹤、訪問攔截、權(quán)限控制等操作，OOP就很難達(dá)到八面玲瓏。
其實(shí)，倒不是OOP一定不能實(shí)現(xiàn)上述功能的分離和重用，但是由于那又需要更高層次的抽象和封裝，憑空增加系統(tǒng)的復(fù)雜性和使用難度，又不利于版本控制和發(fā)布控制，一般來說，是得不償失的。
所以，很多開源項(xiàng)目比如Commons Logging等應(yīng)運(yùn)而生，它們的存在從一定的意義上解決了這個(gè)問題。
但是，還有一種很好的解決方案，那就是AOP（實(shí)際上AOP就是為了解決這種問題而誕生的）。
AOP既然是OOP系統(tǒng)的縱向切割，那么它就應(yīng)該具備以下幾點(diǎn)：
- 切入點(diǎn)（Point Cut）：它需要一個(gè)點(diǎn)來切入到OOP系統(tǒng)中去，目前流行的AOP框架都采用從方法切入的方式。
- 切面（Advice）：切入之后，它要做些什么呢？必須可以有一種方式進(jìn)行定制，目前流行的AOP框架都采用Java代碼實(shí)現(xiàn)的方式
- 重用性：一般來說，AOP能帶來的重用一般都是Advice描述文件的重用，目前所有的AOP的Advice都是Java的Class文件，這就提供了一種可能，所有的Advice都可以通過打包成Jar的形式實(shí)現(xiàn)重用。
由此可以看出，使用AOP能夠帶來的好處是提供了一種抽象模型的方式、一種重用以前工作的方式（在不更改過去的代碼的基礎(chǔ)上添加新的功能、同時(shí)也可以重用過去寫的Advice）。
AOP還有一個(gè)好處，就是減少工作量。
因?yàn)槟壳傲餍械腁OP框架的PointCut定義一般都支持通配，這樣就可以實(shí)現(xiàn)批量定義和修改。如果代碼有著良好的規(guī)范、在良好的設(shè)計(jì)下，開發(fā)和維護(hù)工作量的減少會非常可觀。而且對于添加新的功能不必修改原有的架構(gòu)設(shè)計(jì)，從另一方面也降低了非常可觀的工作量。
那么AOP在JavaEE企業(yè)級應(yīng)用中能夠起什么作用呢？
- 事務(wù)控制：很多業(yè)務(wù)邏輯方法都需要事務(wù)控制，通過通配實(shí)現(xiàn)事務(wù)控制絕對是一個(gè)節(jié)省工作量的好辦法，如果再結(jié)合IOC更加可以脫離事務(wù)控制的依賴，實(shí)現(xiàn)事務(wù)控制靈活更換，提高了業(yè)務(wù)系統(tǒng)的重用性
- 權(quán)限控制：權(quán)限控制到底算不算業(yè)務(wù)邏輯？如果不算，為什么還要體現(xiàn)在業(yè)務(wù)邏輯中？通過AOP的方式，可以靈活的實(shí)現(xiàn)FilterChain機(jī)制，而業(yè)務(wù)邏輯的代碼可以對其毫無察覺。
- 持久層對象的裝飾和過濾：可以根據(jù)需要對持久層操作返回的結(jié)果進(jìn)行裝飾和過濾，甚至替換，而對系統(tǒng)架構(gòu)沒有任何要求。這是最漂亮和最干凈的做法。
- 系統(tǒng)級別診斷日志：實(shí)現(xiàn)可插拔式系統(tǒng)級別日志，這樣在系統(tǒng)正常運(yùn)行后就可以為了提高系統(tǒng)性能而不費(fèi)事的去掉它卻不會影響到系統(tǒng)的穩(wěn)定。
- 業(yè)務(wù)級別高級抽象：比如可以把工作流支持API封裝，通過AOP的機(jī)制實(shí)現(xiàn)Mixin，這樣就可以實(shí)現(xiàn)工作流支持和原業(yè)務(wù)邏輯分離，可以分開進(jìn)行管理，也可以在更高的抽象級別上實(shí)現(xiàn)重用。
AOP也不是沒有缺點(diǎn)，它本身就有一定的學(xué)習(xí)曲線，而且目前為止有具體意愿的好的實(shí)踐并不多，而且它也會給你的工程帶來復(fù)雜性，它還會給你的代碼增加理解的難度（不管你承認(rèn)不承認(rèn)，代碼閱讀的難度確實(shí)是跟代碼的耦合程度反相關(guān)的——雖然這是設(shè)計(jì)模式所力圖解決的問題）
但是，目前來看適當(dāng)?shù)氖褂肁OP，給你的項(xiàng)目提高靈活性和可維護(hù)性，是值得的。