AOP 的利器：ASM 3.0 介紹

引言

什么是 ASM？

ASM 是一個 Java 字節碼操控框架。它能被用來動態生成類或者增強既有類的功能。ASM 可以直接產生二進制 class 文件，也可以在類被加載入 Java 虛擬機之前動態改變類行為。Java class 被存儲在嚴格格式定義的 .class 文件里，這些類文件擁有足夠的元數據來解析類中的所有元素：類名稱、方法、屬性以及 Java 字節碼（指令）。ASM 從類文件中讀入信息后，能夠改變類行為，分析類信息，甚至能夠根據用戶要求生成新類。

與 BCEL 和 SERL 不同，ASM 提供了更為現代的編程模型。對于 ASM 來說，Java class 被描述為一棵樹；使用 “Visitor” 模式遍歷整個二進制結構；事件驅動的處理方式使得用戶只需要關注于對其編程有意義的部分，而不必了解 Java 類文件格式的所有細節：ASM 框架提供了默認的 “response taker”處理這一切。

為什么要動態生成 Java 類？

動態生成 Java 類與 AOP 密切相關的。AOP 的初衷在于軟件設計世界中存在這么一類代碼，零散而又耦合：零散是由于一些公有的功能（諸如著名的 log 例子）分散在所有模塊之中；同時改變 log 功能又會影響到所有的模塊。出現這樣的缺陷，很大程度上是由于傳統的 面向對象編程注重以繼承關系為代表的“縱向”關系，而對于擁有相同功能或者說方面 （Aspect）的模塊之間的“橫向”關系不能很好地表達。例如，目前有一個既有的銀行管理系統，包括 Bank、Customer、Aclearcase/" target="_blank" >ccount、Invoice 等對象，現在要加入一個安全檢查模塊， 對已有類的所有操作之前都必須進行一次安全檢查。

然而 Bank、Customer、Account、Invoice 是代表不同的事務，派生自不同的父類，很難在高層上加入關于 Security Checker 的共有功能。對于沒有多繼承的 Java 來說，更是如此。傳統的解決方案是使用 Decorator 模式，它可以在一定程度上改善耦合，而功能仍舊是分散的 —— 每個需要 Security Checker 的類都必須要派生一個 Decorator，每個需要 Security Checker 的方法都要被包裝（wrap）。下面我們以 Account 類為例看一下 Decorator：

首先，我們有一個 SecurityChecker 類，其靜態方法 checkSecurity 執行安全檢查功能：

public class SecurityChecker {
public static void checkSecurity() {
System.out.println("SecurityChecker.checkSecurity ...");
//TODO real security check
}
}

原文轉自：http://www.kjueaiud.com