在紛繁複雜的程式設計世界裡，我們總是需要儘可能的考慮到各種情況。而有這麼一種機制，我們可以將我們指責中的一部分隔離開來，讓一個所謂的代理來幫我們解決一部分和主體業務關係不大的業務，從而讓我們能更專心的設計我們的主體業務。這就是代理模式的初衷，也是很多流行框架的應用。——個人理解。

一、代理模式(Proxy)的定義

為其他物件提供一種代理以控制對這個物件的訪問。在某些情況下，一個物件不合適或者不能直接引用另一個物件，而代理物件可以在客戶端和目標物件之間起到中介的作用。

二、應用場景

1. 遠端代理：也就是為一個物件在不同的地址空間提供區域性代表。這樣可以隱藏一個物件存在不同地址空間的事實。例如：WebService、
   RPC、RMI(Remote Method Invocation)等。
2. 虛擬代理：是根據需要建立開銷很大的物件。通過它來存放例項化需要很長時間的真實物件。例如：利用虛擬代理來優化頁面的開啟速度。
3. 安全代理：用來控制真實物件訪問時的許可權。一般使用者物件應該在不同訪問許可權的時候。
4. 智慧指引：是指當呼叫真實的物件時，代理處理另外一些事情。例如：Spring AOP、Hibernate等。
   

注:以上的代理並非只是簡單的代理模式的應用，而是使用了下一篇介紹的動態代理的概念。但是思想其實都是一樣的。

三、結構圖

四、程式碼表示

4.1 抽象角色

通過介面或者抽象類宣告真實角色實現的業務方法。

package com.xiaocao.proxy;

/**
 *  Subject類，定義了RealSubject和Proxy的公共介面
 *  這樣就在任何事喲娜RealSubject的地方都可以使用Proxy 
 */
public abstract class Subject {
    public abstract void Request();
}

4.2 代理角色

實現抽象角色，是真實角色的代理，通過真實角色的業務邏輯方法來實現抽象方法，並可以附加自己的操作。

package com.xiaocao.proxy;

/**
 *  Proxy類，儲存一個引用使得使用代理可以訪問實體，
 *  並提供一個與Subject相同的介面，這樣代理就可以用來替代實體
 */
 

public class Proxy extends Subject{

    private RealSubject realSubject;

    public void Request() {
        if (realSubject == null) {
            realSubject = new RealSubject();
        }
        realSubject.Request();
    }
}

4.3 真實角色

實現抽象角色，定義真實角色所要實現的業務邏輯，供代理角色呼叫。

package com.xiaocao.proxy;
/**
 *  RealSubject類，定義了Proxy所代表的真實實體 
 */
public class RealSubject extends Subject{
    public void Request() {
        System.out.println("真實的請求");
    }
}

4.4 測試類

package com.xiaocao.proxy;

/**
 *  測試類
 */
public class Test {
    public static void main(String[] args) {
        Proxy proxy = new Proxy();
        proxy.Request();
    }
}

執行結果很簡單：當呼叫代理的時候輸出“真實的請求”。

五、代理模式的簡單認識

1. 代理模式思想上很簡單，但是往往在應用上並不是那麼簡單。因為在實際開發中，往往我們在開發階段並不知道抽象角色是誰，到時候我們需要根據客戶的需求，動態的生成代理。這就是應用的關鍵了——動態代理。
2. 代理模式本身其實並沒有多麼高明之處，重要的是如何應用代理模式而實現的業務邏輯。就像簡單的紙張本身其實並沒有什麼價值，而紙張上寫的文字才是最重要的。我個人覺得應用最深刻的應該就是AOP面向切面程式設計的思想了吧。而在分散式中最常見的就是WebService和RPC了吧。似乎阿里的dubbo更是對RPC良好封裝。

六、優缺點

優點

1. 職責清晰
   真實的角色就是實現實際的業務邏輯，不用關心其他非本職責的事務，通過後期的代理完成一件完成事務，附帶的結果就是程式設計簡潔清晰。
2. 代理物件可以在客戶端和目標物件之間起到中介的作用，這樣起到了的作用和保護了目標物件的作用。
3. .高擴充套件性

缺點

借用一句忠告，一個專案或者模組中最多不要超過5中設計模式，不然就是過度封裝。這其實是所有開發者應該注意的東西。

注意：轉載請標明，轉自itboy-木小草。
尊重原創，尊重技術。