Java 的代理，動態代理，靜態代理

備註：簡單總結，望指正！

看完代碼，現在我來回答，動態代理的作用是什麼：

1. Proxy類的代碼量被固定下來，不會因爲業務的逐漸龐大而龐大；
2. 可以實現AOP編程，實際上靜態代理也可以實現，總的來說，AOP可以算作是代理模式的一個典型應用；
3. 解耦，通過參數就可以判斷真實類，不需要事先實例化，更加靈活多變。

① 首先你要明白靜態代理的作用
我們有一個字體提供類，有多種實現（從磁盤，從網絡，從系統）

public interface FontProvider {
    Font getFont(String name);
}

public abstract class ProviderFactory {
    public static FontProvider getFontProvider() {
        return new FontProviderFromDisk();
    }
}

public class Main() {
    public static void main(String[] args) {
        FontProvider fontProvider = ProviderFactory.getFontProvider();
        Font font = fontProvider.getFont("微軟雅黑");
        ......
    }
}

現在我們希望給他加上一個緩存功能，我們可以用靜態代理來完成

public class CachedFontProvider implements FontProvider {
    private FontProvider fontProvider;
    private Map<String, Font> cached;

    public CachedFontProvider(FontProvider fontProvider) {
        this.fontProvider = fontProvider;
    }

    public Font getFont(String name) {
        Font font = cached.get(name);
        if (font == null) {
            font = fontProvider.getFont(name);
            cached.put(name, font);
        }
        return font;
    }
}


/* 對工廠類進行相應修改，代碼使用處不必進行任何修改。
   這也是面向接口編程以及工廠模式的一個好處 */
public abstract class ProviderFactory {
    public static FontProvider getFontProvider() {
        return new CachedFontProvider(new FontProviderFromDisk());
    }
}

當然，我們直接修改FontProviderFromDisk類也可以實現目的，但是我們還有FontProviderFromNet, FontProviderFromSystem等多種實現類，一一修改太過繁瑣且易出錯。
況且將來還可能添加日誌，權限檢查，異常處理等功能顯然用代理類更好一點。

② 然而爲什麼要用動態代理？
考慮以下各種情況，有多個提供類，每個類都有getXxx(String name)方法，每個類都要加入緩存功能，使用靜態代理雖然也能實現，但是也是略顯繁瑣，需要手動一一創建代理類。

public abstract class ProviderFactory {
    public static FontProvider getFontProvider() {...}
    public static ImageProvider getImageProvider() {...}
    public static MusicProvider getMusicProvider() {...}
    ......
}

使用動態代理怎麼完成呢？

public class CachedProviderHandler implements InvocationHandler {
    private Map<String, Object> cached = new HashMap<>();
    private Object target;

    public CachedProviderHandler(Object target) {
        this.target = target;
    }

    public Object invoke(Object proxy, Method method, Object[] args)
        throws Throwable {
        Type[] types = method.getParameterTypes();
        if (method.getName().matches("get.+") && (types.length == 1) &&
                (types[0] == String.class)) {
            String key = (String) args[0];
            Object value = cached.get(key);
            if (value == null) {
                value = method.invoke(target, args);
                cached.put(key, value);
            }
            return value;
        }
        return method.invoke(target, args);
    }
}

public abstract class ProviderFactory {
    public static FontProvider getFontProvider() {
        Class<FontProvider> targetClass = FontProvider.class;
        return (FontProvider) Proxy.newProxyInstance(targetClass.getClassLoader(),
            new Class[] { targetClass },
            new CachedProviderHandler(new FontProviderFromDisk()));
    }
}

③ 這也是爲什麼Spring這麼受歡迎的一個原因
Spring容器代替工廠，Spring AOP代替JDK動態代理，讓面向切面編程更容易實現。
在Spring的幫助下輕鬆添加，移除動態代理，且對源代碼無任何影響。

總結

一個典型的動態代理創建對象過程可分爲以下四個步驟：
1、通過實現InvocationHandler接口創建自己的調用處理器 IvocationHandler handler = new InvocationHandlerImpl(...);
2、通過爲Proxy類指定ClassLoader對象和一組interface創建動態代理類
Class clazz = Proxy.getProxyClass(classLoader,new Class[]{...});
3、通過反射機制獲取動態代理類的構造函數，其參數類型是調用處理器接口類型
Constructor constructor = clazz.getConstructor(new Class[]{InvocationHandler.class});
4、通過構造函數創建代理類實例，此時需將調用處理器對象作爲參數被傳入
Interface Proxy = (Interface)constructor.newInstance(new Object[] (handler));
爲了簡化對象創建過程，Proxy類中的newInstance方法封裝了2~4，只需兩步即可完成代理對象的創建。
生成的ProxySubject繼承Proxy類實現Subject接口，實現的Subject的方法實際調用處理器的invoke方法，而invoke方法利用反射調用的是被代理對象的的方法（Object result=method.invoke(proxied,args)）

美中不足

誠然，Proxy已經設計得非常優美，但是還是有一點點小小的遺憾之處，那就是它始終無法擺脫僅支持interface代理的桎梏，因爲它的設計註定了這個遺憾。回想一下那些動態生成的代理類的繼承關係圖，它們已經註定有一個共同的父類叫Proxy。Java的繼承機制註定了這些動態代理類們無法實現對class的動態代理，原因是多繼承在Java中本質上就行不通。有很多條理由，人們可以否定對 class代理的必要性，但是同樣有一些理由，相信支持class動態代理會更美好。接口和類的劃分，本就不是很明顯，只是到了Java中才變得如此的細化。如果只從方法的聲明及是否被定義來考量，有一種兩者的混合體，它的名字叫抽象類。實現對抽象類的動態代理，相信也有其內在的價值。此外，還有一些歷史遺留的類，它們將因爲沒有實現任何接口而從此與動態代理永世無緣。如此種種，不得不說是一個小小的遺憾。但是，不完美並不等於不偉大，偉大是一種本質，Java動態代理就是佐例。