由遇到的問題引出代理模式
至少在以下集中情況下可以用代理模式解決問題：
- 創建開銷大的對象時候，比如顯示一幅大的圖片，我們將這個創建的過程交給代理去完成，GoF 稱之為虛代理（Virtual Proxy）；
- 為網絡上的對象創建一個局部的本地代理，比如要操作一個網絡上的一個對象（網絡性能不好的時候，問題尤其突出），我們將這個操縱的過程交給一個代理去完成，GoF 稱之為遠程代理（Remote Proxy）；
- 對對象進行控制訪問的時候，比如在 Jive 論壇中不同權限的用戶（如管理員、普通用戶等）將獲得不同層次的操作權限，我們將這個工作交給一個代理去完成，GoF 稱之為保護代理（Protection Proxy）。
UML 圖:
角色：
- Subject: 抽象角色。聲明真實對象和代理對象的共同接口。
- Proxy: 代理角色。代理對象與真實對象實現相同的接口，所以它能夠在任何時刻都能夠代理真實對象。代理角色內部包含有對真實對象的引用，所以她可以操作真實對象，同時也可以附加其他的操作，相當于對真實對象進行封裝。
- RealSubject: 真實角色。它代表著真實對象，是我們最終要引用的對象
舉例：
假若你有一個工廠開始是生產手機的，但是它現在不想自己生產了，它把自己的東西交給了一家代工廠富士康去生產，那么便有了下面的代碼去構建。
統一的抽象接口 IFactory
class IFactory { public: IFactory(){} virtual void makeProduct() = 0; }; 你的手機工廠
class PhoneFactory : IFactory { public: PhoneFactory(){} void makeProduct() { cout<<"生產手機"<<endl; } }; 專門做代工的代理工廠富士康
class FoxconnProxy : IFactory { public: FoxconnProxy(IFactory* factory) { m_real = factory; } void makeProduct() { m_real->makeProduct(); } private: IFactory* m_real; }; 客戶端：
IFactory* factory = new PhoneFactory(); FoxconnProxy* proxy = new FoxconnProxy(factory); proxy->makeProduct();
看了uml圖和上面的代碼你會可能會發現，先訪問代理類再訪問真正要訪問的對象。似乎這樣有點多此一舉的味道，其實不然。代理類可以在真正的類執行之前，進行預處理。 比富士康生產的手機之前可能會堅持元器件是否合格，不合格就不生產等。在比如你有一個系統實現了登陸功能，在用戶登錄時, 真正的登錄類和代理登錄類都實現了Login接口, 不同的是Proxy類的方法中增加了用戶是否合法的判斷, 只有合法時才去調用真正登錄類的login方法. 用戶訪問的其實是Proxy的login方法.這都是代理模式的優點。而且采用代理模式的話，并且你可以隨時更改代理。還有一點你會發現，真正對象與代理他們實現同一個接口。
這個模式和裝飾者模式有點類似之處，都是包裝，但是請注意他們應用場景不一樣：一個是動態的給類添加職責，一個是控制對這個對象的訪問。最重要的一點不同是他們的結構不同，你對比下兩個模式的uml圖便知。
