躲不過設計模式的坑之代理模式
作者：指北君
代理模式確實對于目標對象有保護作用，也方便了目標對象的擴展，但凡事都有兩面性，它也不是完美的，由于多了代理層，請求處理增加處理過程，進而會降低響應速度，同時也增加了系統(tǒng)復雜性，維護成本會有些增加。
?哈嘍，大家好，我是指北君。又是全新的一天，從一起進步開始，先來段向上語錄，共勉。
不一定努力就會有回報，但堅持是成功的另一個名字。
前言
設計模式在我看來更像是一種設計思維或設計思想，它就像《孫子兵法》一樣，為你的項目工程提供方向，讓你的項目工程更加健壯、靈活，延續(xù)生命力。本文即將分享的是設計模式的其中一種：代理模式。
?代理模式
- 通用官方定義：代理模式（Proxy Pattern) 是一種結(jié)構(gòu)型設計模式，通過代理對象控制對原對象的訪問，并允許在訪問前或訪問后做一些處理。
- 簡單理解就是給一個對象找了一個替代品，這個替代品得到原對象授權(quán)，可以攔截一些無效或低效的訪問，從而使得原對象可以釋放時間做自己的事情。這樣替代品實現(xiàn)了自己價值，原對象也得到了解放，兩全其美的選擇??！
- 代理主要分為以下幾種類型
靜態(tài)代理：僅用于單個接口實現(xiàn)類，程序運行前已經(jīng)存在。調(diào)用時需要傳入具體實例，調(diào)用方可以直接獲取具體實例。
動態(tài)代理：可以服務多個接口實現(xiàn)類，可以在程序運行時，通過反射機制動態(tài)創(chuàng)建代理對象。?
使用場景
既然這么說了，那就結(jié)合實際介紹幾個??，還不是輕松拿捏~
- 場景一：作為一個氣血方剛的男青年，汽車總是繞不開的話題，那就先以汽車為例。
4s店或汽車廠家均可以出售汽車，對于購車消費者來說，可以直接去喜歡的汽車店去體驗成品，不必跋山涉水的跨省或跨市去汽車廠家。有了4S店代理，可以節(jié)省消費者時間，更快體驗到心儀的汽車，最終也是通過汽車廠家拿到成品；同時汽車工廠通過這些代理，可以更快售出汽車，可謂是一舉兩得。關(guān)系類圖如下：
- 場景二：上面講述的是靜態(tài)代理的案例，再來一個最近實踐的動態(tài)代理需求場景。
人力業(yè)務平臺接入了不同客戶，同時為了滿足客戶不同的接入需求，采用動態(tài)代理模式會為每個客戶動態(tài)生成代理對象，比如需要提取客戶A的簡歷數(shù)據(jù)，根據(jù)客戶A的標識獲取代理類并執(zhí)行對應的實現(xiàn)邏輯，從而獲取客戶A的數(shù)據(jù)信息。關(guān)系如下
?代碼分析
- 結(jié)合上述動態(tài)代理業(yè)務場景，按照UML類型進行代碼設計，來演示下整體過程。首先將數(shù)據(jù)提取接口（IHandlerService）抽象出來，同時提供一個通用實現(xiàn)（HandlerServiceImpl）。
/*
* 通用接口
* */
public interface IHandlerService {
/*
* 抽取數(shù)據(jù)
* */
void handle();
/**
* 打印內(nèi)容
*
* @param content 輸出內(nèi)容
*/
String print(String content);
/**
* 設置信息
*
* @param prefix 信息前綴
*/
void setPrefix(String prefix);
}
/*
* 通用實現(xiàn)
* */
@Service
public class HandlerServiceImpl implements IHandlerService {
/*
* 默認信息前綴
* */
private String prefix = "default";
@Override
public void handle() {
System.out.println("=======自定義實現(xiàn)類" + prefix + "======");
}
@Override
public String print(String content) {
System.out.println(prefix + " 實現(xiàn)類輸出 -》" + content);
return prefix + "success";
}
@Override
public void setPrefix(String prefix) {
this.prefix = prefix;
}
}
- 接下來創(chuàng)建個代理類，變量包含通用接口，也可以增加業(yè)務所需的其它變量。（java動態(tài)代理核心內(nèi)容：InvocationHandler接口和Proxy類，代理對象在執(zhí)行函數(shù)時，會通過InvocationHandler接口的invoke調(diào)用執(zhí)行函數(shù)）具體代碼如下：
public class MultiDynamicProxy implements InvocationHandler {
/**
* @see InvocationHandler
* 每個代理實例的調(diào)用處理程序必須實現(xiàn)的接口，當通過代理實例調(diào)用方法時，
* 這個方法的調(diào)用會被轉(zhuǎn)發(fā)至實現(xiàn)InvocationHandle接口類的invoke方法去執(zhí)行
*/
private static Map<String, IHandlerService> map = new HashMap<>();
public static String key = "default";
private void addElements(String key) {
if (map.containsKey(key)) return;
IHandlerService handlerService = new HandlerServiceImpl();
handlerService.setPrefix(key);
map.put(key, handlerService);
}
public static IHandlerService newInstance(IHandlerService handlerService) {
MultiDynamicProxy handlerProxy = new MultiDynamicProxy(handlerService);
// 抽象邏輯接口
Class<IHandlerService> handlerServiceClass = IHandlerService.class;
/**
* param1：指定接口（interface）的類加載器，用于裝入定義的代理類
* param2：動態(tài)代理類要實現(xiàn)的接口
* param3：將執(zhí)行的代理方法調(diào)用派發(fā)給代理類（程序）
* */
return (IHandlerService) Proxy.newProxyInstance(handlerServiceClass.getClassLoader(),
new Class[]{handlerServiceClass}, handlerProxy);
}
public MultiDynamicProxy(IHandlerService handlerService) {
map.put(key, handlerService);
}
/*
* 自定義實現(xiàn)類對象替換代理類對象，并執(zhí)行
* param1：proxy 方法被調(diào)用的代理實例，即真實的代理對象
* param2：method 代理對象的method對象
* param3：args 代理對象方法傳遞的參數(shù)
* */
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
System.out.println("=====代理類執(zhí)行====" + proxy.getClass().getSimpleName());
Object invoke = method.invoke(getElement(), args);
return invoke;
}
private IHandlerService getElement() {
if (null == map.get(key)) {
addElements(key);
}
return map.get(key);
}
- 小編在每個環(huán)節(jié)都增加了日志輸出，就很容易理解每個環(huán)節(jié)都做了哪些處理，日志內(nèi)容請接著往下看
public static void main(String[] args) {
IHandlerService handlerService = MultiDynamicProxy.newInstance(new HandlerServiceImpl());
String s = handlerService.print("客戶A");
System.out.printf("執(zhí)行結(jié)果 => " + s);
}
// 輸出結(jié)果
// =====代理類執(zhí)行====$Proxy0
// default 實現(xiàn)類輸出 -》客戶A
// 執(zhí)行結(jié)果 => defaultsuccess
- 觀察結(jié)果可以看出，執(zhí)行的service實例確實為代理對象（$Proxy0），后續(xù)可以動態(tài)接入客戶實現(xiàn)，并注冊到客戶信息集合，當然，也可以對實現(xiàn)類進行擴展，但考慮到通用性，所以接口職責盡可能保持單一，避免業(yè)務交叉，造成后續(xù)的維護困難。
總結(jié)
以上就是本文所分享的全部內(nèi)容，靜態(tài)代理部分由于相對比較簡單，就沒寫代碼，主要是動態(tài)代理，理解上比較容易，但是具體的執(zhí)行過程確實需要仔細分析，才能明白其實現(xiàn)原理。
代理模式確實對于目標對象有保護作用，也方便了目標對象的擴展，但凡事都有兩面性，它也不是完美的，由于多了代理層，請求處理增加處理過程，進而會降低響應速度，同時也增加了系統(tǒng)復雜性，維護成本會有些增加。
沒有最完美的設計模式，只有最適合業(yè)務場景的設計模式。
責任編輯：武曉燕
來源：
Java技術(shù)指北
