阿里P6+面試：介紹下觀察者模式？
消息隊列(MQ)，一種能實現生產者到消費者單向通信的通信模型，這也是現在常用的主流中間件。
常見有 RabbitMQ、ActiveMQ、Kafka等 他們的特點也有很多 比如 解偶、異步、廣播、削峰 等等多種優勢特點。
在設計模式中也有一種模式能有效的達到解偶、異步的特點，那就是觀察者模式又稱為發布訂閱模式。
今天阿丙就分享一下實際開發中比較常見的這種模式
大綱
定義
什么是觀察者模式?他的目的是什么?
- 當一個對象的狀態發生改變時，已經登記的其他對象能夠觀察到這一改變從而作出自己相對應的改變。通過這種方式來達到減少依賴關系，解耦合的作用。
舉一個例子，就好比微信朋友圈，以當前個人作為訂閱者，好友作為主題。一個人發一條動態朋友圈出去，他的好友都能看到這個朋友圈，并且可以在自主選擇點贊或者評論。
感覺有點抽象，還是看看他有哪些主要角色：
- Subject(主題): 主要由類實現的可觀察的接口，通知觀察者使用attach方法，以及取消觀察的detach方法。
- ConcreteSubject(具體主題): 是一個實現主題接口的類，處理觀察者的變化
- Observe(觀察者): 觀察者是一個由對象水岸的接口，根據主題中的更改而進行更新。
這么看角色也不多，但是感覺還是有點抽象，我們還是用具體實例代碼來走一遍吧，我們還是以上面的朋友圈為例看看代碼實現
- public interface Subject {
- // 添加訂閱關系
- void attach(Observer observer);
- // 移除訂閱關系
- void detach(Observer observer);
- // 通知訂閱者
- void notifyObservers(String message);
- }
先創建一個主題定義，定義添加刪除關系以及通知訂閱者
- public class ConcreteSubject implements Subject {
- // 訂閱者容器
- private List<Observer> observers = new ArrayList<Observer>();
- @Override
- public void attach(Observer observer) {
- // 添加訂閱關系
- observers.add(observer);
- }
- @Override
- public void detach(Observer observer) {
- // 移除訂閱關系
- observers.remove(observer);
- }
- @Override
- public void notifyObservers(String message) {
- // 通知訂閱者們
- for (Observer observer : observers) {
- observer.update(message);
- }
- }
- }
其次再創建的具體主題，并且構建一個容器來維護訂閱關系，支持添加刪除關系，以及通知訂閱者
- public interface Observer {
- // 處理業務邏輯
- void update(String message);
- }
創建一個觀察者接口，方便我們管理
- public class FriendOneObserver implements Observer {
- @Override
- public void update(String message) {
- // 模擬處理業務邏輯
- System.out.println("FriendOne 知道了你發動態了" + message);
- }
- }
最后就是創建具體的觀察者類，實現觀察者接口的update方法，處理本身的業務邏輯
- public class test {
- public static void main(String[] args) {
- ConcreteSubject subject = new ConcreteSubject();
- // 這里假設是添加好友
- subject.attach(new FriendOneObserver());
- FriendTwoObserver twoObserver = new FriendTwoObserver();
- subject.attach(twoObserver);
- // 發送朋友圈動態
- subject.notifyObservers("第一個朋友圈消息");
- // 輸出結果：FriendOne 知道了你發動態了第一個朋友圈消息
- // FriendTwo 知道了你發動態了第一個朋友圈消息
- // 這里發現 twoObserver 是個推薦賣茶葉的，刪除好友
- subject.detach(twoObserver);
- subject.notifyObservers("第二個朋友圈消息");
- // 輸出結果：FriendOne 知道了你發動態了第二個朋友圈消息
- }
- }
最后就是看測試結果了，通過ConcreteSubject 維護了一個訂閱關系，在通過notifyObservers 方法通知訂閱者之后，觀察者都獲取到消息從而處理自己的業務邏輯。
這里細心的朋友已經達到了解耦合的效果，同時也減少了依賴關系，每個觀察者根本不要知道發布者處理了什么業務邏輯，也不用依賴發布者任何業務模型，只關心自己本身需要處理的邏輯就可以了。
如果有新的業務添加進來，我們也只需要創建一個新的訂閱者，并且維護到observers 容器中即可，也符合我們的開閉原則。
這里只是一種同步的實現方式，我們還可以擴展更多其他的異步實現方式，或者采用多線程等實現方式。
框架應用
觀察者模式在框架的中的應用也是應該很多
- 第一種 熟悉JDK的人應該知道 在java.util 包下 除了常用的 集合 和map之外還有一個Observable類，他的實現方式其實就是觀察者模式。里面也有添加、刪除、通知等方法。
這里需要注意是的 他是用Vector 作為訂閱關系的容器，同時在他的定義方法中都添加synchronized關鍵字修飾類，以達到線程安全的目的
這里我貼出了關鍵源碼，感興趣的同學可以自己打開并且觀看每個方法的注釋。
- 第二種 在Spring中有一個ApplicationListener，也是采用觀察者模式來處理的，ApplicationEventMulticaster作為主題，里面有添加，刪除，通知等。
spring有一些內置的事件，當完成某種操作時會發出某些事件動作，他的處理方式也就上面的這種模式，當然這里面還有很多，我沒有細講，有興趣的同學可以仔細了解下Spring的啟動過程。
import java.util.EventListener;/** * Interface to be implemented by application event listeners. * Based on the standard {@code java.util.EventListener} interface * for the Observer design pattern. // 這里也已經說明是采用觀察者模式 * *
- import java.util.EventListener;
- /**
- * Interface to be implemented by application event listeners.
- * Based on the standard {@code java.util.EventListener} interface
- * for the Observer design pattern. // 這里也已經說明是采用觀察者模式
- *
- * <p>As of Spring 3.0, an ApplicationListener can generically declare the event type
- * that it is interested in. When registered with a Spring ApplicationContext, events
- * will be filtered accordingly, with the listener getting invoked for matching event
- * objects only.
- *
- * @author Rod Johnson
- * @author Juergen Hoeller
- * @param <E> the specific ApplicationEvent subclass to listen to
- * @see org.springframework.context.event.ApplicationEventMulticaster //主題
- */
- @FunctionalInterface
- public interface ApplicationListener<E extends ApplicationEvent> extends EventListener {
- /**
- * Handle an application event.
- * @param event the event to respond to
- */
- void onApplicationEvent(E event);
- }
- 第三種 Google Guava的事件處理機制Guava EventBus 他的實現也是采用設計模式中的觀察者設計模式。
EventBus 當前實現有兩種方式：
- EventBus // 同步阻塞模式
- AsyncEventBus // // 異步非阻塞模式
EventBus內部也提供來一系列的方法來供我們方便使用：
- register 方法作為添加觀察者
- unregister方法刪除觀察者
- post 方法發送通知消息等
使用起來非常方便。添加@Subscribe注解就可以創建一個訂閱者了，具體的使用方式可以看看官網。
現實業務改造舉例
框架應用的例子這么多，在業務場景中其實也有很多地方可以使用到，這里我還是給大家舉一個例子。
在新用戶注冊成功之后我們需要給用戶做兩件事情，第一是發送注冊成功短信，第二是給用發送新人優惠券。
看到這個問題 大家可能首先會想到用MQ消息處理呀，是的，用消息確實可以的，但是這里我們用觀察者模式來實現這個問題，同時可以給大家演示一下，同步或者異步的問題。
- public class SendNewPersonCouponObserver implements Observer {
- ExecutorService pool = Executors.newFixedThreadPool(2);
- @Override
- public void update(String message) {
- Future<String> future = pool.submit(new Callable<String>() {
- @Override
- public String call() throws Exception {
- TimeUnit.SECONDS.sleep(3);
- // 處理響應的業務邏輯
- return "調用發券服務，返回結果";
- }
- });
- try {
- // 假設等待200毫秒 沒有獲取到返回值結果則認為失敗
- System.out.println(future.get(4000, TimeUnit.MILLISECONDS));
- } catch (Exception e) {
- // 執行異步獲取失敗
- // 記錄日志，定時任務重試等
- }
- // 第一種不關心返回值結果
- Thread thread = new Thread(new Runnable() {
- @SneakyThrows
- @Override
- public void run() {
- // 模擬服務調用 線程睡3秒鐘
- TimeUnit.SECONDS.sleep(3);
- System.out.println("發送新人優惠券");
- }
- });
- thread.start();
- System.out.println("執行異步返回");
- }
- }
- public class SendSuccessMessageObserver implements Observer {
- @Override
- public void update(String message) {
- // 處理業務邏輯
- System.out.println("注冊成功");
- }
- public static void main(String[] args) {
- // 假設用戶注冊成功直接通知觀察者，改干自己的事情了
- ConcreteSubject subject = buildSubject();
- subject.notifyObservers("");
- }
- private static ConcreteSubject buildSubject() {
- ConcreteSubject subject = new ConcreteSubject();
- subject.attach(new SendSuccessMessageObserver());
- subject.attach(new SendNewPersonCouponObserver());
- return subject;
- }
- }
這里我們新寫了兩個觀察者，主要看第一個SendNewPersonCouponObserver，這里了異步開啟新的線程去處理我們的業務邏輯，當我們關心返回值的時候可以用Future來獲取返回結果，當不關心的返回值的化，直接開啟普通線程就可以了。
這個舉例整體其實還是比較簡單的主要是為了說清楚異步線程處理，當然如果用Guava EventBus也可以實現。而且也不復雜，感興趣的朋友可以自己去試試。
當前現在有更加好的中間件MQ消息隊列來處理這個業務問題，使得我們更加從容的面對這類場景問題，但是一些資源不足，不想引入新的系統。還是可以用這種方式來處理問題的。
設計模式學習的不是代碼，而是學習每種模式的思想，他們分別處理的是什么業務場景。
總結
大家看完本篇文章不知道有發現沒有，其實整個內容都是圍繞了解耦的思想來寫的，觀察者模式作為行為型設計模式，主要也是為了不同的業務行為的代碼解耦。
合理的使用設計模式可以使代碼結構更加清晰，同時還能滿足不同的小模塊符合單一職責，以及開閉原則，從而達到前面寫工廠模式說的，提高代碼的可擴展性，維護成本低的特點。
我是敖丙你知道的越多，你不知道的越多，我們下期見。
