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