04 java 訂閱者模式(觀察者模式(Observer Pattern))

源 source :openWindows

通知一個事件源 source :openWindows

doOpen something...

到這里你應該非常清楚的了解，什么是事件監聽器模式了吧。 那么哪里是回調接口，哪里是回調者，對！EventListener是一個回調接口類，handleEvent是一個回調函數接口，通過回調模型，EventSource 事件源便可回調具體監聽器動作。

有了了解后，這里還可以做一些變動。 對特定的事件提供特定的關注方法和事件觸發

public class EventSource {

...

public void onCloseWindows(EventListener eventListener){

System.out.println("關注關閉窗口事件");

ListenerList.add(eventListener);

}

}

public static void main(String[] args) {

EventSource windows = new EventSource();

/

**

* 另一種實現方式

*/

//關注關閉事件，實現回調接口

windows.onCloseWindows(new EventListener(){

}

這種就類似于，我們的窗口程序，Button監聽器了。我們還可以為單擊、雙擊事件定制監聽器。

觀察者模式

什么是觀察者模式

觀察者模式其實原理和監聽器是一樣的，使用的關鍵在搞清楚什么是觀察者、什么是被觀察者。

觀察者(Observer)相當于事件監器。有個微博模型比較好理解，A用戶關注B用戶，則A是B的觀察者，B是一個被觀察者，一旦B發表任何言論，A便可以獲得。

被觀察者(Observable)相當于事件源和事件，執行事件源通知邏輯時，將會回調observer的回調方法update。

舉個例子

為了方便，同樣我直接使用jdk自帶的Observer。

一個觀察者

public class WatcherDemo implements Observer {

@Override

public void update(Observable o, Object arg) {

if(arg.toString().equals("openWindows")){

System.out.println("已經打開窗口");

}

}

}

被觀察者

Observable 是jdk自帶的被觀察者，具體可以自行看源碼和之前的監聽器事件源類似。

主要方法有

addObserver() 添加觀察者，與監聽器模式類似

notifyObservers() 通知所有觀察者

類Watched.java的實現描述：被觀察者，相當于事件監聽的事件源和事件對象。又理解為訂閱的對象 主要職責：注冊/撤銷觀察者（監聽器），接收主題對象（事件對象）傳遞給觀察者（監聽器），具體由感興趣的觀察者（監聽器）執行

/

**

}

測試執行

public static void main(String[] args) {

Watched watched = new Watched();

WatcherDemo watcherDemo = new WatcherDemo();

watched.addObserver(watcherDemo);

watched.addObserver(new Observer(){

@Override

public void update(Observable o, Object arg) {

if(arg.toString().equals("closeWindows")){

System.out.println("已經關閉窗口");

}

}

});

//觸發打開窗口事件，通知觀察者

watched.notifyObservers("openWindows");

//觸發關閉窗口事件，通知觀察者

watched.notifyObservers("closeWindows");

控制臺輸出：

已經打開窗口

已經關閉窗口

總結

從整個實現和調用過程來看，觀察者和監聽器模式基本一樣。

有興趣的你可以基于這個模型，實現一個簡單微博加關注和取消的功能。 說到底，就是事件驅動模型，將調用者和被調用者通過一個鏈表、回調函數來解耦掉，相互獨立。

“你別來找我，有了我會找你”。

整個設計模式的初衷也就是要做到低耦合，低依賴。

再延伸下，消息中間件是什么一個模型？ 將生產者+服務中心（事件源）和消費者（監聽器）通過消息隊列解耦掉. 消息這相當于具體的事件對象，只是存儲在一個隊列里（有消峰填谷的作用），服務中心回調消費者接口通過拉或取的模型響應。 想必基于這個模型，實現一個簡單的消息中間件也是可以的。

還比如gava ListenableFuture，采用監聽器模式就解決了future.get()一直阻塞等待返回結果的問題。

有興趣的同學，可以再思考下觀察者和責任鏈之間的關系， 我是這樣看的。

同樣會存在一個鏈表，被觀察者會通知所有觀察者，觀察者自行處理，觀察者之間互不影響。 而責任鏈，講究的是擊鼓傳花，也就是每一個節點只需記錄繼任節點，由當前節點決定是否往下傳。 常用于工作流，過濾器web filter。

很赞哦!（5384）