Aspectj 實作Method條件運作

  面對這樣的需求初級程式員有些人肯定會覺得沒什麼了不起的啊，不就是幾個if/else或者switch/case。我和我的團隊對代碼有一種天生的潔癖，對于太多複雜的if/else和switch/case，以及将來會被移除的臨時非産品代碼分布在各處，有一種抵觸心理。

對于有一定工作經驗的程式員來說這樣的需求肯定也不是什麼問題，不就是aop（面向切面程式設計），對，這就是我們所期望的解決方案，把處理的邏輯集中，和産品代碼的分離。

知道了用aop，也許你隻對了一半，在aop的世界裡，有兩種實作方式靜态植入和動态代理，最早了aop實作采用的是靜态植入，然後由于ioc之類的架構的興起，動态代理的實作方式也逐漸興起，取代了靜态植入的方式。但并不是說靜态植入的方式就不再有用武之地的，在這裡我們所采用的aop架構aspectj就是一個靜态注入的架構，我們并沒有和spring結合，動态代理的方式有個基本的問題就是你不能直接new這個對象這需要交給架構處理，如果是spring架構的話，這要求你必須是一個spring的bean，以及動态代理會有一些性能的損失。這對于該場景的限制太多，并不是我所期望的。

這裡簡述如何實作：

1 對于aop第一步是比對規則，是以定義一個标記：

其指向一個實作runner接口的類型。

2：有了比對規則，我們就可以找到切入點進行aop邏輯的處理，

  這裡在切入方法調用之前，new了一個配置的runner類型（注意必須午餐構造），并調用其exec方法擷取是否運作該方法，如果不運作則傳回什麼預設值。

exec的參數簽名為方法簽名資訊和方法運作時參數。

    一切都這麼簡單，現在你可以任意的架構runner去做适合你的場景業務了。可以參照項目下得sample執行個體，該執行個體展示了一個當出入參數為3的時候執行，部位3則傳回預設值1.

   想想還有那些場景，你是否遇見過某類單元測試我隻希望運作在某種固定的場景下？假設在開發圖形應用的時候，我們希望調用一些不同平台的特定api，雖然我們代碼設計封裝做得很好，但是我們希望有固定的內建測試去cover這部分邏輯，讓我們的測試隻運作是固定平台。