設計模式在我看來更像是一種設計思維或設計思想，它就像《孫子兵法》一樣，為你的項目工程提供方向，讓你的項目工程更加健壯、靈活，延續生命力。本文即將分享的是設計模式的其中一種：代理模式。

代理模式

• 通用官方定義： 代理模式 （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），后續可以動態接入客戶實現，并注冊到客戶信息集合，當然，也可以對實現類進行擴展，但考慮到通用性，所以接口職責盡可能保持單一，避免業務交叉，造成后續的維護困難。

總結

• 以上就是本文所分享的全部內容，靜態代理部分由于相對比較簡單，就沒寫代碼，主要是動態代理，理解上比較容易，但是具體的執行過程確實需要仔細分析，才能明白其實現原理。
• 代理模式確實對于目標對象有保護作用，也方便了目標對象的擴展，但凡事都有兩面性，它也不是完美的，由于多了代理層，請求處理增加處理過程，進而會降低響應速度，同時也增加了系統復雜性，維護成本會有些增加。
• 沒有最完美的設計模式，只有最適合業務場景的設計模式。