跳到主要內容

代理人模式 (Proxy Pattern)

        代理人模式如同字面上的意思,就是做事情時(如取得某些資料),是透過代理人,而不是直接跟提供資料的物件構通。先來看看此模式的正式定義及類別圖:

代理人模式讓某個物件具有一個替身,藉以控制外界對此物件的影響。
Provide a surrogate or placeholder for another object to control access to it.


        從類別圖可以看到, Subject 是共用的介面,可以讓客戶將 Proxy 物件視為 RealSubject 物件來處理。RealSubject 是真正做事的物件,被 Proxy 代理, Proxy 可以控制 RealSubject 的存取。Proxy 持有 RealSubject 的參考,客戶和 RealSubject 的互動都要透過 Proxy,在某些情形下這樣的限制是必要的,如 RealSubject 是遠端物件, RealSubject 建立成本高等等。

        此模式有許多種變形,都是依據上面的原則而發展出來的。以下介紹 深入淺出設計模式(Head First Design Patterns) 裡面提到的一些應用方式:

        1. 遠端代理人(Remote):算是最常使用到的應用方式。在網路中或是跨 Process 的各種程式,不可能直接存取(assess) 不同程式間的物件,因此就需要遠端代理人。 Java RMI 和 Android AIDL 都算是遠端代理人的實踐。

        2. 虛擬代理人(Virtual):代理的對象是建立很花費資源的物件。當物件建立前和建立中,由虛擬代理人扮演代理的角色。物件建立完成後,代理人就會將讓求直接轉給物件。以下為簡單範例程式:

// Proxy 實作跟 RealSubject 共同的介面 Icon
public class ImageProxy implements Icon {

    // 這是我們的 RealSubject,
    // 也就是真正要顯示圖的物件
    private ImageIcon mImageIcon;
    private URL mUrl;
    private Thread mRetrievalThread;
    private boolean mRetrieving = false;

    // 此範例是從網路上取得圖
    public ImageProxy(URL url)
    {
        mUrl = url;
    }

    @Override
    public int getIconWidth()
    {
        // 在圖下載完成前, 先傳回預設的值
        if(mImageIcon != null)
        {
            return mImageIcon.getIconWidth();
        }
        else
        {
            return 0;
        }
    }

    @Override
    public int getIconHeight()
    {
        // 在圖下載完成前, 先傳回預設的值
        if(mImageIcon != null)
        {
            return mImageIcon.getIconHeight();
        }
        else
        {
            return 0;
        }
    }

    @Override
    public int paintIcon(...)
    {
        // 圖下載好了, 畫圖的事就轉給
        // RealSubject 做
        if(mImageIcon != null)
        {
            mImageIcon.paintIcon(...);
        }
        else
        {
            // 第一次下載圖
            drawString("Loading icon, please wait...");
            if(!mRetrieving)
            {
                mRetrieving = true;

                mRetrievalThread = new Thread(new Runnable() {

                    @Override
                    public void run()
                    {
                        mImageIcon = new ImageIcon(mUrl, "icon");
                    }
                });
                mRetrievalThread.start();
            }
        }
    }
}
        3. 保護代理人(Protection):根據客戶的權限決定是否能存取物件。如果需要,可以針對不同客提供不同權限。

// Proxy 實作跟 RealSubject 共同的介面 CarBase
public class CarProxy implements CarBase {

    // 這是我們的 RealSubject
    private CarBase mCar;
    private Driver mDriver;

    public CarProxy()
    {
        mCar = new Car();
    }

    @Override
    public int driveCar(Driver driver)
    {
        // 確認客戶是否達到開車年齡
        if(driver.getAge() < 18)
        {
            System.out.println("Driver is too young to drive.");
        }
        else
        {
            mCar.driveCar();
        }
    }
}

        4. 防火牆代理人( Firewall):控制網路資源的存取,保護內部免於受到外面的侵害。常用於公司的防火牆系統。

        5. 聰明參考代理人(Smart Reference):當物件被參考到時,進行額外的動作,例如計算此物件被參考的次數。

        6. 備用代理人(Caching):將耗資源的運算結果暫存起來,供後續使用,以減少成本。常用於 Web Proxy。

        7. 同步化代理人(Synchronization):提供安全的存取,讓多個執行緖存取同一個物件時不會出錯。

// Proxy 實作跟 RealSubject 共同的介面 TableBase
public class RowLockTableProxy extends TableBase {

    private TableBase mTable;
    private Object[] mLocks;

    public RowLockTableProxy(TableBase table)
    {
        mTable = table;

        // 針對不同 row 建立不同 lock
        mLocks = new Object[mTable.numOfRows()];
        for(int i = 0; i < mTable.numOfRows(), i++)
        {
            mLocks[i] = new Object();
        }
    }

    @Override
    public Object getElementAt(int row, int column)
    {
        synchronized (locks[row])
        {
            return realTable.getElementAt(row, column);
        }
    }

    @Override
    public int numOfRows()
    {
        return mTable.numOfRows();
    }
}

        8. 隱藏複雜代理人(Complexity Hiding):用來對一群複雜的類別,進行複雜度隱藏以及存取控制。有時也被稱為表象代理人(Facade Proxy)。要注意的是這和表象模式是不一樣的,因為代理人控制存取,而表象模式只提供另一組介面。

        9. 寫入時複製代理人(Copy-On-Write):用來控制物件的複製,將複製的動作拖延到客戶真的需要為止,這是虛擬代理人的變形。可以參考 Java 或 Android 的 CopyOnWriteArrayList 實作。

        看到這邊我們可以發現,上面提到的代理人變形都跟「控制存取」有關。有人可能有疑問,覺得代理人模式跟裝飾者模式一樣,都是把物件包裝起來,再把調用傳遞過去,這樣有什麼區別?注意裝飾者是增加物件的行為,而代理人是控制物件的存取。而用虛擬代理人的例子來看,客戶如果直接存取 ImageIcon,就必須等圖下載完,且等的時候不能做其他事(不能顯示訊息)。在這裡代理人就是控制 ImageIcon 的存取,要等圖真的下載完成才允許客戶存取 ImageIcon。

        也有人可能會覺得代理人模式跟轉接器模式很像。雖然他們兩個都是客戶和物件之間的中間層,負責將請求轉給真正的物件,但轉接器會改變物件的介面,而代理人是實作相同的介面

參考資料:

        深入淺出設計模式(Head First Design Patterns)

留言

這個網誌中的熱門文章

訪問者模式 (Visitor Pattern)

        假設你設計一個系統,其中會有一些相似類別,類別中都有某些方法內容相似,但還是需要判斷目前要做事的是哪個類別才能呼叫對應的適當類別。通常遇到這種情情,在 Java 中最直接的做法就是使用 instanceof 關鍵字來判斷,如以下的簡單範例: public interface CarComponent { public void printMessage(); } public class Wheel implements CarComponent { @Override public void printMessage() { System.out.println("This is a wheel"); } // 這是 Wheel 跟 Engine 不同的方法 public void doWheel() { System.out.println("Checking wheel..."); } } public class Engine implements CarComponent { @Override public void printMessage() { System.out.println("This is a engine"); } // 這是 Wheel 跟 Engine 不同的方法 public void doEngine() { System.out.println("Testing this engine..."); } } public class Car { private List mComponents; public Car() { mComponents = new ArrayList<carcomponent>(); } // 有些時候我們還是需要針對不同類別去做不同的事情 public void setComponent(CarCompon...

解譯器模式 (Interpreter Pattern)

        解譯器模式簡單來說就是 把一句有特殊規則的語句,透過解釋器將它真正的意思表現出來 。相信有學過 Context-free grammar (CFG),Backus–Naur form (BNF),或是 Compiler 相關程的人會比較了解這個模式 (不是我,我早就忘光了…)。不知道上面術語的人,還是可以透過接下來的介紹來稍微了解這個模式。先來看一下這個模式的正式定義及類別圖: 定義一個語言與其文法,使用一個解譯器來表示這個語言的敘述 Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language Context 通常是指待解譯的語句 AbstractExpression 是所有規則都要實作的介面 TerminalExpression 是指無法再展開的規則,算是最小單位的規則 NonterminalExpression 是指可以再展開的規則,可以展開成 NonterninalExpression 和 TerminalExpression 的組合         從類別圖可以看到,語法可能可以一直展開,這時就可以用語法樹來表示,而語法樹以程式來表達的話,就可以使用 合成模式 。而通常比較正式的語法會用 BNF 來表示,如下: expression ::= plus | minus | variable | number plus ::= expression expression '+' minus ::= expression expression '-' variable ::= 'a' | 'b' | 'c' | ... | 'z' digit = '0' | '1' | ... | '9' number ::= digit | digit number 而 每個語法都會定義一個類別 ,如 pl...

狀態模式 (State Pattern)

        如果今天你要設計一台如下圖的糖果機,你會怎麼設計呢?         有上過資訊相關課程的人,應該不難從上圖聯想到 狀態圖 ,上圖中每個圓圈都是一個狀態,而每個箭頭就代表狀態的轉換。有了這個概念後,把它轉成程式就不難了: public class CandyMachine { // 以下四個值表示糖果機會用到的狀態 final static int SOLD_OUT = 0; final static int NO_COIN = 1; final static int HAS_COIN = 2; final static int SOLD = 3; // 需要有一個變數來記錄目前的狀態 // 初始設為賣完, 因為一開始機器裡沒糖果 int mState = SOLD_OUT; // 也要有另一個變數記錄目前剩多少顆糖果 int mCount = 0; public CandyMachine(int count) { mCount = count; // 機器內有糖果的話就跳到沒投錢的狀態, // 表示糖果機在等人投錢 if(mCount > 0) { mState = NO_COIN; } } // 當投錢時會執行這個方法 public void insertCoin() { if(mState == HAS_COIN) { System.out.println("You can't insert another coin"); } else if(mState == NO_COIN) { mState == HAS_COIN; System.out.println("You inserted a coin"); } ...