面向切面程序設計（AOP）近年來備受關注，而 AspectJ 作為 AOP 在 Java 語言上的實現，廣受 Java 開發者青睞。網路上關於 AspectJ 的資料多半從語法入手，講解如何應用 AspectJ 分離日誌、事務、安全驗證等切面。但初學者常感困惑：AspectJ 究竟如何運作？是否需要特殊運行環境？本文將從設計思路與運行原理切入，揭開 AspectJ 的神秘面紗。
AspectJ 的本質是一個代碼生成工具。其語法實際上是定義代碼生成規則的領域特定語言（DSL），這與 Java Compiler Compiler (JavaCC) 的代碼生成理念驚人相似。AspectJ 擁有專屬編譯器（ajc），編譯產出標準 Java Class 文件，運行時僅需在 classpath 中加入 AspectJ Runtime Library（aspectjrt.jar）。
物件導向程序設計（OOP）擅長封裝數據與行為，卻難以優雅解決橫切關注點的分離。以銀行業務為例：
class Bank {
public float deposit(AccountInfo account, float money) { /* 業務邏輯 */ }
public float withdraw(AccountInfo account, float money) { /* 業務邏輯 */ }
}
當需求加入安全驗證、事務控制等非業務邏輯時，傳統做法是硬編碼植入各方法，導致代碼重複、耦合度高。雖可用 Template Pattern 重構，但強制統一方法簽名，缺乏彈性。AOP 正是為解決此類「切面分離」問題而生。
EJB 透過部署描述符（ejb-jar.xml）集中定義事務、安全等屬性，由容器實現。其優點是業務代碼純淨，缺點是侷限於 EJB 容器環境。
AspectJ 無需修改原有代碼，僅定義切面：
aspect AuthAspect {
pointcut bankMethods() : execution(* Bank.deposit(..)) || execution(* Bank.withdraw(..));
Object around(): bankMethods() {
// 驗證用戶合法性
return proceed();
}
}
aspect TransactionAspect {
pointcut bankMethods() : execution(* Bank.deposit(..)) || execution(* Bank.withdraw(..));
Object around(): bankMethods() {
// 開啟事務
Object result = proceed();
// 提交/回滾事務
return result;
}
}
AspectJ 編譯器讀取切面定義，根據 pointcut（切入點）與 advice（增強）自動織入代碼，生成含有驗證與事務邏輯的 Bank 類。這本質上是編譯期代碼生成，而非運行時動態代理。
xDoclet 擴展 Javadoc 標籤（@tag），從源碼註解生成代碼或配置文件。它處理分散在代碼中的標籤，而 AspectJ 與 EJB Descriptor 則集中管理切面。三者互補，體現了「分久必合，合久必分」的演進規律。
AspectJ 並非黑魔法，而是基於靜態編譯織入的代碼生成器。理解其原理，有助於打破對新技術的迷信，回歸技術本質。開源技術推動軟體發展，關鍵在於掌握核心機制，而非盲目追逐概念。
