跳到主要內容

備忘錄模式 (Memento Pattern)

        備忘錄模式的用途很單純,就是提供物件回到之前狀態的功能,簡單說就是備份 (存檔) 的機制。備忘錄模式是一個在現實世界中很常使用到的模式,如遊戲的儲存記錄,文書編輯器的「上一步」功能等。簡單介紹完這個模式後,就來看一下正式的定義及類別圖吧:

不違反封裝的情形下,取得物件的內部狀態。如此可以回復物件之前的狀態。
Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later.



  • Originator:就是定義中提到的要保留內部狀態的物件。現實例子就像是遊戲角色狀態,或是文書編輯器中的文字等。
  • Memento:保留 Originator 內部狀態 (資料) 的物件,例如遊戲中要存檔的資料。
  • Caretaker:主要功用是管理 Memento 物件。
        看上面的介紹,可能有人會有疑惑,為什麼不要 Originator 自己處理存檔功能就好,還要花心力額外獨立出存檔跟管理存檔的物件?這樣做的目的其實是為了讓類別的權責單一化(單一責任守則:一個類別應該只有一個改變的理由。)。以生活中的例子來說,不把遊戲記錄檔獨立出來,你要怎麼拿到你朋友的超強記錄呢XD 而且 Caretaker 能管理的不是只有一個 Memento 物件,就好比文書編輯器通常不可能只「上一步」一次,要是把處理多個狀態的功能,以及保留目前狀態的功能,都放在 Originator,Originator 功能會太複雜,未來也不好維護。

        看到這邊,我們應該能知道備忘錄模式有兩個目標:
  • 儲存物件的重要狀態
  • 維護物件的封裝
        接下來來看簡單的程式碼來看備忘錄模式是如何運作的:
// Originator
public class GamePlayer {

    // 遊戲角色的生命值
    private int mHp;

    // 遊戲角色的經驗值
    private int mExp;

    public GamePlayer(int hp, int exp)
    {
        mHp = hp;
        mExp = exp;
    }

    public GameMemento saveToMemento()
    {
        return new GameMemento(mHp, mExp);
    }

    public void restoreFromMemento(GameMemento memento)
    {
        mHp = memento.getGameHp();
        mExp = memento.getGameExp();
    }

    public void play(int hp, int exp)
    {
        mHp = mHp - hp;
        mExp = mExp + exp;
    }
}

// Memento
public class GameMemento {

    // 假設只有這兩個資料要保留
    private int mGameHp;
    private int mGameExp;

    public GameMemento(int hp, int exp)
    {
        mGameHp = hp;
        mGameExp = exp;
    }

    public int getGameHp()
    {
        return mGameHp;
    }

    public int getGameExp()
    {
        return mGameExp;
    }
}

// Caretaker
public class GameCaretaker {

    // 保留要處理的資料。
    // 這邊只是範例,所以 Caretaker
    // 只能處理一個 Memento。
    // 實務上當然可以用更複雜的結構來
    // 處理多個 Memento,如 ArrayList。
    private GameMemento mMemento;

    public GameMemento getMemento()
    {
        return mMemento;
    }

    public void setMemento(GameMemento memento)
    {
        mMemento = memento;
    }
}

public class Demo {

    public static void main(String[] args)
    {
        // 創造一個遊戲角色
        GamePlayer player = new GamePlayer(100, 0);

        // 先存個檔
        GameCaretaker caretaker = new GameCaretaker();
        caretaker.setMemento(player.seveToMemento());

        // 不小心死掉啦
        player.play(-100, 10);

        // 重新讀取存檔,又是一尾活龍
        player.restoreFromMemento(caretaker.getMemento());
    }
}
        最後來總結一下吧。備忘錄模式的用途就是提供備份功能,因此這個模式的架構本身就設計的容易實作復原功能。也因為拆成了 Originator,Memento,Caretaker,除了讓物件的資料封裝不被破壞外,也提高了內聚力 (cohesion)。雖然範例的備份復原很簡單,但實務上 Memento 要保留的資料可能很多,會造成備份還原的時間很長,這是要注意的部份。另外,Java SDK 本身的 Serializable 以及 Android SDK 的 Parcelable 都算是很好的備忘錄模式實作,有興趣的人可以參考。

參考資料:

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

留言

這個網誌中的熱門文章

訪問者模式 (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...

裝飾者模式 (Decorator Pattern)

        假如你有一間飲料店, 目前只有賣幾種咖啡。因為生意很好, 因此想更換菜單…         以下是目前菜單的類別圖:         簡單說明此類別圖, cost() 是抽象的, 子類別要實作自己的 cost() 來告知飲料的價格。         買咖啡時, 也可要求要加料, 例如牛奶(Milk)、摩卡(Mocha,就是巧克力口味)。這樣的新類別要如何設計呢 ? 看起來是不能直接新增所需的子類別, 例如 EspressoWithMilk, EspressoWithMilkAndMocha, DarkRoastWithMilk, DarkRoastWithMilkAndMocha… 這樣加下去, 日後飲料跟配料越來越多時, 類別也就越多, 這實在不是個好設計。         換個方式設計呢, 在 Beverage 裡面加入所有的配料如何 ? 這樣好像也不太好, 未來要是配料有更動, Beverage 程式碼就要重寫, 而未來要是有新口味的飲料時, 有些配料就不太合理 ( 薑茶加摩卡 ? ), 更麻煩的是, 無法應付機車的客人 (例如要加 3 份牛奶)。這時候裝飾者模式就能上場啦。在介紹裝飾者模式前, 先說明其設計守則: 類別應該開放, 以便擴充 ; 應該關閉, 禁止修改。         我們的目標是允許類別容易擴充, 在不修改現有程式碼的情形就能搭配新的行為。這樣的設計具有彈性, 可以接受新功能以達到改變需求的目的。這看起來好像有點矛盾, 但是的確有一些技術可以在不直接修改程式碼的情形下進行擴充, 如裝飾者模式。         這時候應該有人會問: 那是不是以後我的專案架構設計都遵循這個守則就是好設計了 ? 答案是不太可能, 也沒這必要, 就算做得到, 也可能是浪費, 容易導致程式碼複雜且難以理解。只需小心選擇哪些部分未來會擴充, 這些部份遵循這個設計守則即可。         接下來...

狀態模式 (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"); } ...