代理模式 Proxy

“接口隔離”模式

• 在元件建構過程中，某些接口之間直接的依賴常常會帶來很多問題、甚至根本無法實作。采用添加一層間接（穩定）接口，來隔離本來互相緊密關聯的接口是一種常見的解決方案。
• 典型模式

1. Facade
2. Proxy
3. Adapter
4. Mediator

動機（Motivation）

• 在面向對象系統中，有些對象由于某種原因（比如對象建立的開銷很大，或者某些操作需要安全控制，或者需要程序外的通路等）直接通路會給使用者、或者系統結構帶來很多麻煩。
• 如何在不失去透明操作對象的同時來管理/控制這些對象特有的複雜性？增加一層間接層是軟體開發中常見的解決方式。 //透明操作：穩定，一緻性。控制對象的複雜：隔離變化。

類圖

結構很簡單，使用起來有可能很複雜。

代碼示例

一般的正常操作有可能是這樣的(僞代碼)：

class ISubject{
public:
    virtual void process();
};


class RealSubject: public ISubject{
public:
    virtual void process(){
        //....
    }
};


class ClientApp{    
    ISubject* subject;
    
public:
    
    ClientApp(){
        subject=new RealSubject(); // 實際有可能拿不到這個東西
    }
    
    void DoTask(){
        //...
        subject->process();        
        //....
    }
};      

實際有可能拿不到 RealSubject 這個對象。

代理模式(僞代碼)：

class ISubject{
public:
    virtual void process();
};


//Proxy的設計
class SubjectProxy: public ISubject{    
public:
    virtual void process(){
        //對RealSubject的一種間接通路
        //....  這裡實作有可能很複雜
    }
};

class ClientApp{    
    ISubject* subject;    
public:    
    ClientApp(){
        subject=new SubjectProxy(); // 有可能用工廠什麼的包裝起來
    }
    
    void DoTask(){
        //...
        subject->process();
        
        //....
    }
};      

要點總結

• “增加一層間接層”是軟體系統中對許多複雜問題的一種常見解決方法。在面向對象系統中，直接使用某些對象會帶來很多問題，作為間接層的proxy對象便是解決這一問題的常用手段。
• 具體proxy設計模式的實作方法、實作粒度都相差很大，有些可能對單個對象做細粒度的控制，如copy-on-write技術，有些可能對元件子產品提供抽象代理層，在架構層次對對象做proxy。
• Proxy并不一定要求保持接口完整的一緻性，隻要能夠實作間接控制，有時候損及一些透明性是可以接受的。

以分布式的例子來解釋這個模式，會大量的使用。不是太明白怎麼使用。

設計模式看到這，個人的感覺：1) 實體類用來做資料的通信 2)接口用來做行為的通信。