前言
青春總是那樣，逝去了才開始回味；大學生活也是在不經意間就溜走了，現在上班的時候，偶爾還會懷念大學時，大家在一起玩游戲的時光。大學喜歡玩游戲，但是可悲的校園網，速度能把人逼瘋了；還好，后來搞了一個游戲代理，總算能勉勉強強的玩了兩年。時至今日，敲起鍵盤寫設計模式的時候，又想起了那些美好的時光。好了，這是一篇技術文章，而不是抒情懷舊的散文；思緒再回到這篇文章上來，游戲代理，是個什么東西，有了它就能讓我們玩游戲的延遲立馬下來了。今天，我并不會去總結游戲代理是如何實現的，重點是通過游戲代理這個例子來總結設計模式中的代理模式。
什么是代理模式？
在GOF的《設計模式:可復用面向對象軟件的基礎》一書中對代理模式是這樣說的：為其他對象提供一種代理以控制對這個對象的訪問。結合上面的游戲代理的例子和下面的圖，我們來進行分析一下。以前你是這樣玩游戲：
現在有了游戲代理，你是這樣玩游戲：
代理服務器干了什么？它代替你去和游戲服務器進行交互。它訪問游戲服務器的速度比你使用校園網訪問游戲服務器的速度快很多。所以，你的游戲延遲就下來了。
代理模式分為四類：遠程代理，虛代理，保護代理和智能引用。在下面使用場合會對這四種進行分別介紹。
UML類圖
Proxy
1.保存一個引用使得代理可以訪問實體。若RealSubject和Subject的接口相同，Proxy會引用Subject，就相當于在代理類中保存一個Subject指針，該指針會指向RealSubject；
2.提供一個與Subject的接口相同的接口，這樣代理就可以用來替代實體；
3.控制對實體的存取，并可能負責創建和刪除它；
4.其它功能依賴于代理的類型，例如：
遠程代理負責對請求及其參數進行編碼，并向不同地址空間中的實體發送已編碼的請求；
虛代理可以緩存實體的附加信息，以便延遲對它的訪問；
保護代理檢查調用者是否具有實現一個請求所必須的訪問權限。
Subject：定義RealSubject和Proxy的共用接口，這樣就在任何使用RealSubject的地方都可以使用Proxy；
RealSubject：定義Proxy所代理的實體。
使用場合
上面也總結了，代理模式分為遠程代理，虛代理，保護代理和智能引用這四種，而分為這四種，就是對應不同的使用場合的。
1.遠程代理為一個對象在不同的地址空間提供局部代理；
2.虛代理根據需求創建開銷很大的對象；
3.保護代理控制原始對象的訪問；保護代理用于對象應該有不同的訪問權限的時候；
4.智能引用取代了簡單的指針，它在訪問對象時執行一些附加操作，它的典型用途包括：
對指向實際對象的引用計數，這樣當該對象沒有引用時，可以自動釋放它；
當第一次引用一個持久對象時，將它裝入內存；
在訪問一個實際對象前，檢查是否已經鎖定了它，以確保其他對象不能改變它。
代碼實現
最簡單的實現，對上述UML類圖的直接代碼體現：
#include <iostream>
using namespace std;
#define SAFE_DELETE(p) if (p) { delete p; p = NULL;}
class CSubject
{
public:
CSubject(){};
virtual ~CSubject(){}
virtual void Request() = 0;
};
class CRealSubject : public CSubject
{
public:
CRealSubject(){}
~CRealSubject(){}
void Request()
{
cout<<"CRealSubject Request"<<endl;
}
};
class CProxy : public CSubject
{
public:
CProxy() : m_pRealSubject(NULL){}
~CProxy()
{
SAFE_DELETE(m_pRealSubject);
}
void Request()
{
if (NULL == m_pRealSubject)
{
m_pRealSubject = new CRealSubject();
}
cout<<"CProxy Request"<<endl;
m_pRealSubject->Request();
}
private:
CRealSubject *m_pRealSubject;
};
int main()
{
CSubject *pSubject = new CProxy();
pSubject->Request();
SAFE_DELETE(pSubject);
}
上面的實現，就是對代理模式的最原始體現，現在提供一個有血有肉的實際應用級的體現：
#include <iostream>
#include <windows.h>
using namespace std;
#define SAFE_DELETE(p) if (p) { delete p; p = NULL; }
class KRefCount
{
public:
KRefCount():m_nCount(0){}
public:
unsigned AddRef(){ return InterlockedIncrement(&m_nCount); }
unsigned Release(){ return InterlockedDecrement(&m_nCount); }
void Reset(){ m_nCount = 0; }
private:
unsigned long m_nCount;
};
template <typename T>
class SmartPtr
{
public:
SmartPtr(void)
: m_pData(NULL)
{
m_pReference = new KRefCount();
m_pReference->AddRef();
}
SmartPtr(T* pValue)
: m_pData(pValue)
{
m_pReference = new KRefCount();
m_pReference->AddRef();
}
SmartPtr(const SmartPtr<T>& sp)
: m_pData(sp.m_pData)
, m_pReference(sp.m_pReference)
{
m_pReference->AddRef();
}
~SmartPtr(void)
{
if (m_pReference && m_pReference->Release() == 0)
{
SAFE_DELETE(m_pData);
SAFE_DELETE(m_pReference);
}
}
inline T& operator*()
{
return *m_pData;
}
inline T* operator->()
{
return m_pData;
}
SmartPtr<T>& operator=(const SmartPtr<T>& sp)
{
if (this != &sp)
{
if (m_pReference && m_pReference->Release() == 0)
{
SAFE_DELETE(m_pData);
SAFE_DELETE(m_pReference);
}
m_pData = sp.m_pData;
m_pReference = sp.m_pReference;
m_pReference->AddRef();
}
return *this;
}
SmartPtr<T>& operator=(T* pValue)
{
if (m_pReference && m_pReference->Release() == 0)
{
SAFE_DELETE(m_pData);
SAFE_DELETE(m_pReference);
}
m_pData = pValue;
m_pReference = new KRefCount;
m_pReference->AddRef();
return *this;
}
T* Get()
{
T* ptr = NULL;
ptr = m_pData;
return ptr;
}
void Attach(T* pObject)
{
if (m_pReference->Release() == 0)
{
SAFE_DELETE(m_pData);
SAFE_DELETE(m_pReference);
}
m_pData = pObject;
m_pReference = new KRefCount;
m_pReference->AddRef();
}
T* Detach()
{
T* ptr = NULL;
if (m_pData)
{
ptr = m_pData;
m_pData = NULL;
m_pReference->Reset();
}
return ptr;
}
private:
KRefCount* m_pReference;
T* m_pData;
};
class CTest
{
public:
CTest(int b) : a(b) {}
private:
int a;
};
int main()
{
SmartPtr<CTest> pSmartPtr1(new CTest(10));
SmartPtr<CTest> pSmartPtr2(new CTest(20));
pSmartPtr1 = pSmartPtr2;
}
智能指針使用引用計數實現時，就是最好的使用代理模式的例子。在上面的例子中，SmartPtr就是一個代理類，而T* m_pData才是實際的數據。SmartPtr代理實際的數據，去實現了指針的行為，添加了引用計數，從而實現了智能指針。
總結
我在第一次接觸代理模式的時候，看它的UML類圖，發現它和適配器模式的類適配器很像，再一看，又和裝飾模式非常像；不仔細區分，真的是很容易混亂的。下面就做簡單的區分，說多了也都是“狡辯”了。
1.適配器Adapter為它所適配的對象提供了一個不同的接口。相反，代理提供了與它的實體相同的接口。然而，用于訪問保護的代理可能會拒絕執行實體會執行的操作，因此，它的接口實際上可能只是實體接口的一個子集。
2.盡管Decorator的實現部分與代理相似，但Decorator的目的不一樣。Decorator為對象添加一個或多個功能，而代理則控制對對象的訪問。
我在這里進行區分，你們看了，也就像我在咬文嚼字一樣；這就是結構型設計模式；它們之間都有一些細微的差別。你也可以說，在適配器模式進行接口適配時，添加一些數據轉換就變成了遠程代理；你也可以說裝飾模式雖然功能不一樣，在我看來，大同小異；是的，不管你怎么說，就像1000個讀者心中有1000個哈姆雷特一樣，每個人對設計模式的理解都是不一樣的；最重要的是我們能在實際應用中進行活學活用，如果能做到這個；不管什么設計模式，那只是一個名字，就像對于富人來說，錢只是一個銀行卡上的一個數字一樣。
最后，我堅信分享使我們更加進步，期待大家和我分享你的設計模式心得。
