您现在的位置：程式碼之家 >> 編程語言 > >> Java 程式設計 >> Java 相關知識

AOP@Work: AOP 與元資料完美結合（二）——多維介面與最佳實踐指南

編輯：Java 相關知識

承接第一部分，本文將元資料視為「多維關注點空間中的簽名」，提出一套系統化的註解設計與使用準則，並探討元資料對 AOP 採用曲線的影響。核心觀點：註解不應僅為切面服務，而應描述程式元素在多個關注點維度上的語義投影，從而實現類別與切面的鬆耦合。

從「主導簽名暴政」到「多維簽名空間」

傳統方法簽名（名稱、參數、回傳型別）只能反映單一核心業務語義（如 credit(float)），無法表達交易、授權、日誌等橫切關注點。強行在名稱編碼橫切資訊（transactional_authorized_credit）會導致簽名糾結：名稱變更波及所有呼叫端，業務呼叫端被迫承擔無關關注點負擔。

Java 5 註解提供了解法：

@Transactional(Required)
@Authorized("accountModification")
public void credit(float amount);

概念上，每個註解代表一個維度的投影：

業務維度 → credit
交易維度 → Required
授權維度 → accountModification

圖 1：使用元資料的多維簽名空間

這構成了多維介面：每個關注點的實作只消費相關維度的投影，業務邏輯完全不知曉交易/授權註解的存在，保持無知性。

實戰範例：銀行帳戶的多維介面

public class Account {
  @Transactional(kind=Required)
  @WriteOperation
  @Authorization(kind="bankModification")
  public void credit(float amount) { ... }

  @Transactional(kind=Required)
  @WriteOperation
  @Authorization(kind="bankModification")
  public void debit(float amount) { ... }

  @Transactional(kind=None)
  @ReadOperation
  @Authorization(kind="bankQuery")
  public float getBalance() { ... }
}

業務呼叫端（AccountServices.transfer()）只見業務維度；交易管理切面只匹配 @Transactional 投影；授權切面只匹配 @Authorization。各維度正交、獨立演進。

五大元資料使用準則

1. 非必要勿用：優先挖掘隱式簽名模式

全域關注點（如效能分析）應用封裝/繼承層級切點（within(com.myapp..*)），而非逐一定點註解。
命名慣例：execution(* *.get*()) 捕獲所有 getter，優於 @Getter。
標準 API 邊界：JDBC、Hibernate、Swing 等具備穩定簽名模式的框架邊界，直接以切點捕獲。
核心原則：先嘗試無註解切點，唯有隱式資訊不足時再引入註解。

2. 善用切面繼承分解子系統

避免單一切面覆蓋全系統導致切點脆弱複雜。建立抽象基底切面（含通知邏與抽象切點），每個子系統（套件、類別）提供具體子切面實作抽象切點。這是 Participant 模式 核心，適用於交易、執行緒安全、安全性等橫切功能。

3. 復用既有領域註解

EJB 3.0 註解（@TransactionAttribute、@RolesAllowed）
Hibernate 註解（表格/欄位/關聯中繼資料）
EMF 註解（類別關係、基數）
切面直接消費這些註解，避免重複標註。

4. 設計抽象註解型別，而非實作導向標記

錯誤：@ReadLock、@WriteLock（綁定鎖實作）
正確：@ReadOperation、@WriteOperation（描述語義狀態變更）

抽象註解允許同一組標註服務多種橫切實作：

讀寫鎖同步切面
髒追蹤/快取切面
「讀操作控制流中不得出現寫操作」防護切面

// 基底切面
public abstract aspect ReadWriteLockSynchronizationAspect 
  perthis(readOperations() || writeOperations()) {
  public abstract pointcut readOperations();
  public abstract pointcut writeOperations();
  // 通知實作鎖邏輯...
}

// 具體子切面：銀行系統
public aspect BankingReadWriteLockSynchronizationAspect 
  extends ReadWriteLockSynchronizationAspect {
  pointcut lockManagedExecution() 
    : execution(* banking.Customer.*(..)) || execution(* banking.Account.*(..));
  public pointcut readOperations() 
    : execution(@ReadOperation * *.*(..)) && lockManagedExecution();
  public pointcut writeOperations() 
    : execution(@WriteOperation * *.*(..)) && lockManagedExecution();
}

5. 註解地獄？引入「註解者-供應者」切面

當大量方法需相同註解組合時，改以切面以橫切方式批量宣告：

// Customer 類別內嵌註解者切面
private static aspect Annotator {
  declare annotation: public Customer.*(..): @Transactional;
}

進階：建立橋接切面將業務註解轉換為橫切註解：

public aspect BusinessTransactionBridge {
  declare annotation: @Purchase *.*(..): @Transactional;
  declare annotation: @OrderProcessing *.*(..): @Transactional;
}

類別僅標註業務語義（@Purchase），橋接切面負責映射至技術切面所需註解，進一步解耦。