由遇到的問題引出代理模式

至少在以下集中情況下可以用代理模式解決問題：

• 創(chuàng)建開銷大的對象時候，比如顯示一幅大的圖片，我們將這個創(chuàng)建的過程交給代理去完成，GoF 稱之為虛代理（Virtual Proxy）；
• 為網(wǎng)絡(luò)上的對象創(chuàng)建一個局部的本地代理，比如要操作一個網(wǎng)絡(luò)上的一個對象（網(wǎng)絡(luò)性能不好的時候，問題尤其突出），我們將這個操縱的過程交給一個代理去完成，GoF 稱之為遠程代理（Remote Proxy）；
• 對對象進行控制訪問的時候，比如在 Jive 論壇中不同權(quán)限的用戶（如管理員、普通用戶等）將獲得不同層次的操作權(quán)限，我們將這個工作交給一個代理去完成，GoF 稱之為保護代理（Protection Proxy）。

UML 圖:

角色：

•        Subject: 抽象角色。聲明真實對象和代理對象的共同接口。
•        Proxy: 代理角色。代理對象與真實對象實現(xiàn)相同的接口，所以它能夠在任何時刻都能夠代理真實對象。代理角色內(nèi)部包含有對真實對象的引用，所以她可以操作真實對象，同時也可以附加其他的操作，相當(dāng)于對真實對象進行封裝。
•        RealSubject: 真實角色。它代表著真實對象，是我們最終要引用的對象

舉例：
   假若你有一個工廠開始是生產(chǎn)手機的，但是它現(xiàn)在不想自己生產(chǎn)了，它把自己的東西交給了一家代工廠富士康去生產(chǎn)，那么便有了下面的代碼去構(gòu)建。

統(tǒng)一的抽象接口 IFactory

class IFactory 
{ 
public: 
  IFactory(){} 
  virtual void makeProduct() = 0; 
}; 

你的手機工廠

class PhoneFactory : IFactory 
{ 
public: 
  PhoneFactory(){} 
  void makeProduct() 
  { 
    cout<<"生產(chǎn)手機"<<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圖和上面的代碼你會可能會發(fā)現(xiàn)，先訪問代理類再訪問真正要訪問的對象。似乎這樣有點多此一舉的味道，其實不然。代理類可以在真正的類執(zhí)行之前，進行預(yù)處理。 比富士康生產(chǎn)的手機之前可能會堅持元器件是否合格，不合格就不生產(chǎn)等。在比如你有一個系統(tǒng)實現(xiàn)了登陸功能，在用戶登錄時, 真正的登錄類和代理登錄類都實現(xiàn)了Login接口, 不同的是Proxy類的方法中增加了用戶是否合法的判斷, 只有合法時才去調(diào)用真正登錄類的login方法. 用戶訪問的其實是Proxy的login方法.這都是代理模式的優(yōu)點。而且采用代理模式的話，并且你可以隨時更改代理。還有一點你會發(fā)現(xiàn)，真正對象與代理他們實現(xiàn)同一個接口。
   這個模式和裝飾者模式有點類似之處，都是包裝，但是請注意他們應(yīng)用場景不一樣：一個是動態(tài)的給類添加職責(zé)，一個是控制對這個對象的訪問。最重要的一點不同是他們的結(jié)構(gòu)不同，你對比下兩個模式的uml圖便知。

最新評論