java设计模式：二、观察者模式

观察者模式

这个模式，在《Head First 设计模式》中以一个气象更新为例来讲的。书中讲的还是不错的，我在这儿总结的时候，不原文照搬了。根据在工作中的运用，以一个贴近工作的例子来总结一下这个所谓的观察者模式。

模式介绍

观察者模式，主要是订阅者和被订阅者之间的关系。当被订阅者发生变化时，订阅者能及时知道它发生了变化。比如我平时喜欢去优酷看一些不错的视频，如果有哪个频道做的节目不错，我就会去订阅它，等它更新的时候，我能第一时间去知道。当然，肯定不止我一个人去订阅这个频道，会有许多和我一样喜欢这个频道的人去订阅它。在这个模型中，我和众多网友便成了订阅者，而不错的频道便成了被订阅者。在观察者模式中，我们便是观察者，频道是被观察者。

1. 需求分析

优酷有一个频道，优酷会员可以订阅这个频道，也可以取消订阅。每次频道有新节目时，第一时间通知用户。

2. 不使用模式

public class UserA {

  private String name;

  public void notified(){
    System.out.println(name + "去看视频...");
  }

  public void setName(String name) {
    this.name = name;
  }
}

public class UserB {

  private String name;

  public void notified(){
    System.out.println(name + "不去看视频...");
  }

  public void setName(String name) {
    this.name = name;
  }

}

public class Channel {

  UserA userA = new UserA();
  UserB userB = new UserB();

  public void update(){
    System.out.println("发布视频到优酷");
    userA.notified();
    userB.notified();
  }
}

如果要新增一个订阅者，需要修改Channel类，新增加一个用户。如果用户取消订阅了，又要修改类，来删除一个。当然，优酷肯定不是这样设计的，这样每增加一个用户，就需要修改一次代码，肯定是受不了的。

3. 使用模式

/**
 * 观察者接口
 */
public interface UserObserve {

  void notified();

}

/**
 * 观察者A
 */
public class UserA implements UserObserve {
  private String name;

  public UserA() {
    this.name = "用户A";
  }

  @Override
  public void notified() {
    System.out.println(name + "选择看视频...");
  }
}

/**
 * 观察者B
 */
public class UserB implements UserObserve {
  private String name;

  public UserB() {
    this.name = "用户B";
  }

  @Override
  public void notified() {
    System.out.println(name + "选择不看视频...");
  }
}

/**
 * 被观察者
 */
public class ChannelObservable {

  private List<UserObserve> userList = new ArrayList<>();

  private boolean hasUpdate = false;

  public void register(UserObserve user) {
    userList.add(user);
  }

  public void remove(UserObserve user) {
    userList.remove(user);
  }

  public void update(){
    //...频道更新了视频
    hasUpdate = true;
    notiry();
  }

  private void notiry(){
    if (hasUpdate) {
      for (UserObserve user : userList) {
        user.notified();
      }
    }
  }

}

/**
 * 测试模式
 */
public class TestObserve {

  public static void main(String[] args) {
    UserObserve userA = new UserA();
    UserObserve userB = new UserB();

    ChannelObservable channelObservable = new ChannelObservable();
    channelObservable.register(userA);
    channelObservable.register(userB);

    channelObservable.update();

  }

}

输出:
用户A选择看视频...
用户B选择不看视频...

使用模式的好处是，无论后面订阅者新增订阅或者取消订阅，都不需要去修改代码，对系统的维护很方便。对于耦合度高低的理解，在之前一直不是特别理解，什么是耦合度。通过工作和学习，慢慢认识了，高耦合给程序的维护带来的多大的不便。
我对耦合度的理解是，当前对象(this)完全去管理了依赖对象的生命周期。什么时间创建依赖对象，什么时间销毁依赖对象，都由当前对象来决定。这样带来的影响就是，在后期如果改变依赖对象时，需要在每个用到的地方都要去做一次修改，程序代码多了，每一次修改，都很有可能出现一些意想不到的bug。
《Head First设计模式》中有一个设计原则：使用面向接口编程。
面向接口编程的好处是，当前对象(this)不需要关心它所依赖的对象是如何实现如何设计的，只要依赖的对象能完成自己想要的结果即可。对于当前对象来说，它依赖的对象是它想象中的一个对象，并没有具体的实现。而面向接口就是编程，正是以这样的思想来设计的。
判断自己的对象与对象是否存在松耦合，只需要定义其抽象接口而不去实现它，然后来判断是否能完成功能，如果可以，那么所设计的结构，是一个完全松耦合的结构，如果不可以，说明耦合度较高。

Guval中的观察者模式

Java自身也带了Observer类。Guval中的EventBus也是一种观察者模式的实现。个人还是比较喜欢Guval中的EventBus。因为它既有同步实现，又有异步实现。
上面的例子，使用EventBus将很容易实现。

/**
 * 自定义EventBus，当然也可以不用自己去定义。
 **/
public class ChannelEventBus {

  private EventBus eventBus = new EventBus();

  public void register(UserObserve user){
    eventBus.register(user);
  }

  public void remove(UserObserve user) {
    eventBus.unregister(user);
  }

  public void update(){
    //...
    eventBus.post("视频更新了。");
  }

}

/**
 * 观察者
 **/
public interface UserObserve {
  @Subscribe
  void notified(String msg);
}

其他方式不变。

如果使用异步，使用AsyncEventBus即可。AsyncEventBus是继承EventBus的，使用方式一样。

总结

观察者模式适合一对多模式下，一的一方做了更新后，通知多的一方去根据更新来做出相应的处理。