總結如下：過濾器實現方式在不保證功能前提下，從性能角度考慮有如下先后順序：Decorator或Proxy模式；AOP攔截器。

考慮使用AOP攔截器時，最好選擇那些受眾面積比較廣的功能，例如一些基礎通用功能：權限檢查；事務機制；Pool等，這些功能不是針對某個具體類或方

法(方法權限除外)，而是一系列類，這樣使用動態AOP攔截器，就是有些性能損耗也是值得的，而且是必要的，使用其他方法也會引起這樣的損耗。

如果過濾器是業務邏輯的一部分，而且在設計時，我們可以確定這些過濾器，這樣我們使用Decorator模式或Proxy模式進行特定指定的攔截，當

然，因為每個類/接口都需要一個附加的Decorator/Proxy，如果某個過濾功能是很多類都需要的，會形成很多Decorator/Proxy附

加類，當點形成面時，這時AOP切面概念就應該浮現在你腦海，這時升級使用AOP攔截器就更好。Decorator/Proxy在點上針對性相當強，特別

在這個點上有一系列過濾器需要實現時。

職責鏈和Decorator/AOP攔截器是有些

區別的，在一個動態運行系統中，有兩個概念：由客戶端觸發的請求對象，該請求對象需要穿透一系列過濾器(防火墻)，最終可能達到持久層數據庫。

Decorator/AOP攔截器是對過濾器管理的一種模式，也就是說：怎么設計過濾器類；過濾器類關系是怎樣；而職責鏈不是對類關系管理定義，而是為了

處理某個請求對象而實現的。他們區別在于目標對象不一樣，所以職責鏈是一種很具體的行為。

在這個層面上，Command模式和其是相競爭的，Command模式類似直接拋繡球，知道目的，能夠最有效率，但是前提在設計編碼階段你必須知道你的目的地；Command模式和職責鏈的區別與Decorator和AOP攔截器的區別是類似的。

總結

以上是生活随笔為你收集整理的aop区别 decorator_Decorator或Proxy模式；AOP拦截器的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。