Decorator模式是
- 對真實對象進行包裝
- 使其功能擴展
- 表現(xiàn)形式：new 包裝類1（new 包裝類2(真實對象)）；這樣真實對象就具備了本身、包裝類1、包裝類2的功能；實現(xiàn)時只需要把真實對象做為包裝類的聚合對象；
Dynamic Proxy模式是
- 將真實對象包裝
- 使其與調(diào)用處理類綁定
- 表現(xiàn)形式：Proxy.newProxyInstance(realObject.getClass().getClassLoader(), realObject.getClass().getInterfaces(), new InvocationHandler(realObj))；這樣真實對象就與InvocationHandler類邦定了，對外是一個代理類的形式；實現(xiàn)時只需要把真實對象做為調(diào)用處理器的聚合對象
==============以下是引用，2007年05月01日增加===============
首先我們來明確一下動態(tài)代理的定義：一個動態(tài)代理類在運行期implements一組interface，使得interface實現(xiàn)類的方法調(diào)用被分派至其他的類(另外的interface實現(xiàn)類或者任意的類)的方法。講得更通俗一些，要了解動態(tài)代理，我們就要知道什么東西動態(tài)了，代理了什么？首先，一個Proxy代理了一組interface的方法。注意，代理的是interface，而不是Class，也不是abstract Class；其次，Proxy具有的型別由綁定的interface所決定的，動態(tài)就體現(xiàn)在此。也許看著這樣的定義，還是會一頭霧水，那么我們畫幅圖來看看吧。
從圖中，我們可以看到Dynamic Proxy并沒有實現(xiàn)Resource這個接口，但是包含了Resource接口實現(xiàn)類的實例；在Dynamic Proxy的create方法中，通過調(diào)用Proxy.newProxyInstance創(chuàng)建一個Proxy，并將該Proxy與Resource接口綁定，最后將Proxy顯式類型轉(zhuǎn)換成Resource接口類型并返回，這樣調(diào)用者就可以通過Proxy調(diào)用interface定義的方法了；由于Proxy與Resource接口綁定了，對Resource接口的方法調(diào)用，都會交由Proxy的invoke方法去處理。而invoke方法會根據(jù)不同的方法，或給以全新的實現(xiàn)，或直接將方法調(diào)用交給Proxy中包含的Resource接口實現(xiàn)類的實例去處理。綜合上面所說的，作為一個Dynamic Proxy，它必須滿足以下三個條件：
1、實現(xiàn)了InvocationHandler接口，實現(xiàn)接口中定義的invoke方法；
2、包含接口實現(xiàn)類的實例；
3、通過Proxy.newProxyInstance方法實現(xiàn)Proxy與接口之間的綁定。
以下代碼給出了一個簡單的Dynamic Proxy實現(xiàn)：
public interface Resource {
public void operationA();
public void operationB();
}
public class ConcreteResource implements Resource {
public void operationA() {
System.out.println("Operation A.");
}
public void operationB() {
System.out.println("Operation B.");
}
}
public class DynamicProxy implements InvocationHandler {
private Resource resource;
public DynamicProxy() {
resource = new ConcreteResource();
}
public Resource create() {
Resource returnResource = null;
returnResource = (Resource) Proxy.newProxyInstance(Resource.class
.getClassLoader(), new Class[] { Resource.class },
this);
return returnResource;
}
public Object invoke(Object obj, Method method, Object[] args) {
Object o = null;
try {
if (method.getName().equals("operationA")) {
System.out.println("OperationA in Proxy");
} else {
o = method.invoke(obj, args);
}
} catch (Exception e) {
e.printStackTrace(); }
return o;
}
}
public class Test {
public static void main(String[] args) {
DynamicProxy proxy = new DynamicProxy();
Resource resource = proxy.create();
resource.operationA();
}
}
目前整個開發(fā)社區(qū)對AOP(Aspect Oriented Programing)推崇備至，也涌現(xiàn)出大量支持AOP的優(yōu)秀Framework,--Spring, JAC, Jboss AOP 等等。AOP似乎一時之間成了潮流。Java初學者不禁要發(fā)出感慨，OOP還沒有學通呢，又來AOP。本文不是要在理論上具體闡述何為AOP, 為何要進行AOP . 要詳細了解學習AOP可以到它老家http://aosd.net去瞧瞧。這里只是意圖通過一個簡單的例子向初學者展示一下如何來進行AOP.
為了簡單起見，例子沒有沒有使用任何第三方的AOP Framework, 而是利用Java語言本身自帶的動態(tài)代理功能來實現(xiàn)AOP.
讓我們先回到AOP本身，AOP主要應用于日志記錄，性能統(tǒng)計，安全控制,事務處理等方面。它的主要意圖就要將日志記錄，性能統(tǒng)計，安全控制等等代碼從商業(yè)邏輯代碼中清楚的劃分出來，我們可以把這些行為一個一個單獨看作系統(tǒng)所要解決的問題，就是所謂的面向問題的編程(不知將AOP譯作面向問題的編程是否欠妥)。通過對這些行為的分離，我們希望可以將它們獨立地配置到商業(yè)方法中，而要改變這些行為也不需要影響到商業(yè)方法代碼。
假設系統(tǒng)由一系列的BusinessObject所完成業(yè)務邏輯功能，系統(tǒng)要求在每一次業(yè)務邏輯處理時要做日志記錄。這里我們略去具體的業(yè)務邏輯代碼。
public interface BusinessInterface {
public void processBusiness();
}
public class BusinessObject implements BusinessInterface {
private Logger logger = Logger.getLogger(this.getClass().getName());
public void processBusiness(){
try {
logger.info("start to processing...");
//business logic here.
System.out.println(“here is business logic”);
logger.info("end processing...");
} catch (Exception e){
logger.info("exception happends...");
//exception handling
}
}
} |
這里處理商業(yè)邏輯的代碼和日志記錄代碼混合在一起，這給日后的維護帶來一定的困難，并且也會造成大量的代碼重復。完全相同的log代碼將出現(xiàn)在系統(tǒng)的每一個BusinessObject中。
按照AOP的思想，我們應該把日志記錄代碼分離出來。要將這些代碼分離就涉及到一個問題，我們必須知道商業(yè)邏輯代碼何時被調(diào)用，這樣我們好插入日志記錄代碼。一般來說要截獲一個方法，我們可以采用回調(diào)方法或者動態(tài)代理。動態(tài)代理一般要更加靈活一些，目前多數(shù)的AOP Framework也大都采用了動態(tài)代理來實現(xiàn)。這里我們也采用動態(tài)代理作為例子。
JDK1.2以后提供了動態(tài)代理的支持，程序員通過實現(xiàn)java.lang.reflect.InvocationHandler接口提供一個執(zhí)行處理器，然后通過java.lang.reflect.Proxy得到一個代理對象，通過這個代理對象來執(zhí)行商業(yè)方法,在商業(yè)方法被調(diào)用的同時，執(zhí)行處理器會被自動調(diào)用。
有了JDK的這種支持，我們所要做的僅僅是提供一個日志處理器。
public class LogHandler implements InvocationHandler {
private Logger logger ＝ Logger.getLogger(this.getClass().getName());
private Object delegate;
public LogHandler(Object delegate){
this.delegate = delegate;
}
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
Object o = null;
try {
logger.info("method stats..." ＋ method);
o = method.invoke(delegate,args);
logger.info("method ends..." + method);
} catch (Exception e){
logger.info("Exception happends...");
//excetpion handling.
}
return o;
}
} |
現(xiàn)在我們可以把BusinessObject里面的所有日志處理代碼全部去掉了。
public class BusinessObject implements BusinessInterface {
private Logger logger = Logger.getLogger(this.getClass().getName());
public void processBusiness(){
//business processing
System.out.println(“here is business logic”);
}
} |
客戶端調(diào)用商業(yè)方法的代碼如下：
BusinessInterface businessImp = new BusinessObject();
InvocationHandler handler = new LogHandler(businessImp);
BusinessInterface proxy = (BusinessInterface) Proxy.newProxyInstance(
businessImp.getClass().getClassLoader(),
businessImp.getClass().getInterfaces(),
handler);
proxy.processBusiness(); |
程序輸出如下：
INFO: method stats...
here is business logic
INFO: method ends... |
至此我們的第一次小嘗試算是完成了。可以看到，采用AOP之后，日志記錄和業(yè)務邏輯代碼完全分開了，以后要改變?nèi)罩居涗浀脑捴恍枰薷娜罩居涗浱幚砥骶托辛耍鴺I(yè)務對象本身（BusinessObject）無需做任何修改。并且這個日志記錄不會造成重復代碼了，所有的商業(yè)處理對象都可以重用這個日志處理器。
當然在實際應用中，這個例子就顯得太粗糙了。由于JDK的動態(tài)代理并沒有直接支持一次注冊多個InvocationHandler，那么我們對業(yè)務處理方法既要日志記錄又要性能統(tǒng)計時，就需要自己做一些變通了。一般我們可以自己定義一個Handler接口，然后維護一個隊列存放所有Handler, 當InvocationHandler被觸發(fā)的時候我們依次調(diào)用自己的Handler。所幸的是目前幾乎所有的AOP Framework都對這方面提供了很好的支持.這里推薦大家使用Spring。