跳到主要內容

觀察者模式 (Observer Pattern)

        用來說明觀察者模式最常見也最容易懂的例子就是報社訂閱報紙:

  1. 報社的主要工作就是出版報紙 (提供資料)
  2. 用戶可向報社訂閱報紙。只要報社有出版新報紙, 而你在報社的訂閱名單中, 你都可以收到最新的報紙。
  3. 當你不想再看報紙時, 可隨時取消訂閱, 報社就不會送報紙到你家。
  4. 只要報社還存在, 用戶就可隨時向報社訂閱或取消訂閱報紙。
        假如你看得懂上面的例子的話, 其實也大概了解觀察者模式在幹什麼。把上面的例子, 報社改名為主題 (Subject), 訂閱者改為觀察者 (Observer), 觀察者模式 = 出版者 + 訂閱者

        更精確的觀察者模式定義為: 觀察者模式定義了物件之間的一對多關係, 如此一來, 當一個物件改變狀態, 其他相依者都會收到通知並自動被更新
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

        以下來看個簡單的觀察者模式類別圖:

        主題介面定義了 registerObserver(), removeObserver(), 可以讓物件變成觀察者, 或從觀察者名單中移除, 而觀察者介面定義了 update(), 當主題有改變時, 可以用來通知所有觀察者。在此介紹觀察者模式的設計守則: 設計時, 盡量讓需要互動的物件之間關係鬆綁。此設計讓我們建立有彈性的 OO 系統, 能夠因應變化, 因為物件的相依性被降到最低。

  1. 關於觀察者的一切, 主題只知道觀察者有實作特定介面 (也就是 Observer 介面)。主題不需要知道觀察者的具體類別為何、做了什麼、及其細節。
  2. 任何時候都可以加入新的觀察者
  3. 有新型態的觀察者出現時, 主題的程式碼不用修改。主題不在乎觀察者實際類別, 只在乎有沒有實作觀察者介面。
  4. 片面改變主題或觀察者, 並不會影響另一方。只要兩邊的介面沒有更改就不會影響。

        了解上面的觀察者模式觀念後, 接下來就來完成報社的程式碼吧~

pubilc interface Subject {
    public void registerObserver(Observer o);
    public void removeObserver(Observer o);
    public void notifyObservers();
}

        主題介面定義了三個 method, 用來新增、刪除、以及通知觀察者。

public interface Observer {
    public void update(String content);
}

        觀察者介面只定義了一個 method, 當有資料更新時(如新報紙), 主題能通知觀察者。注意到我們這邊 update() 傳入的參數為 String 只是單純的範例, 實際上可根據不同需求來設計。

public class NewspaperOffice implements Subject() {

    // 使用 List 來記錄所有訂閱者
    List mObservers;

    // 報紙內容
    String mContent;

    public NewspaperOffice()
    {
        mObservers = new ArrayList();
        mContent = "";
    }

    public void sendNewspaper(String content)
    {
        mContent = content;
        notifyObservers();
    }

    @Override
    public void registerObserver(Observer o)
    {
        mObservers.add(o);
    }

    @Override
    public void removeObserver(Observer o)
    {
        int i = mObservers.indexOf(0);
        if(i > 0)
            mObservers.remove(i);
    }

    @Override
    public void notifyObservers()
    {
        for(int i = 0; i < mObservers.size(); i++)
        {
            Observer o = mObservers.get(i);
            o.update(mContent);
        }
    }
}

public class Customer implements Observer {

    // 訂閱者名稱
    String mName;

    public Customer(String name)
    {
        mName = name;
    }

    @Override
    public void update(String content)
    {
        System.out.println(name + "get newspaper: "
            + content);
    }
}

public class Test {
    public static void main(String[] args)
    {
        // 建立報社
        NewspaperOffice office = new NewspaperOffice();

        // 訂閱者 Tom
        Customer Tom = new Customer("Tom");

        // 訂閱者 Peter
        Customer Peter = new Customer("Peter");

        // 訂閱者訂報紙
        office.registerObserver(Tom);
        office.registerObserver(Peter);

        // 報社送報紙囉
        office.sendNewspaper("Newspaper 1...");

        // Tom 不想訂報紙了
        office.removeObserver(Tom);
        office.sendNewspaper("Newspaper 2...");
    }
}

        以上就是觀察者模式的基本觀念喔。可能有人會想說 update() 裡傳入的是固定參數, 要是未來需求改變, update() 不就要一直更改 ? 簡單的作法是主題提供一些 getter method,讓觀察者在收到 update() 時自己去向主題要自己感興趣的資料。其他更好的方法就自行思考囉。



參考資料:

深入淺出設計模式(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...

代理人模式 (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 { // 這是我們的 RealSubje...