原创

详解设计模式—观察者模式(Observer Pattern)

定义

Define a one-to-many dependency between objects so that when one object changes state,all its dependents are notified and updated automatically.(定义对象间一种一对多的依赖关系,使得每当一个对象改变状态,则所有依赖于它的对象都会得到通知并被自动更新。)

对象行为型模式

角色

  • 抽象主题(Subject):也叫抽象目标类,它提供了一个用于保存观察者对象的聚集类和增加、删除观察者对象的方法,以及通知所有观察者的抽象方法。
  • 具体主题(Concrete Subject):也叫具体目标类,它实现抽象目标中的通知方法,当具体主题的内部状态发生改变时,通知所有注册过的观察者对象。
  • 抽象观察者(Observer):它是一个抽象类或接口,它包含了一个更新自己的抽象方法,当接到具体主题的更改通知时被调用。
  • 具体观察者(Concrete Observer):实现抽象观察者中定义的抽象方法,以便在得到目标的更改通知时更新自身的状态。

类图

20190717105409984.png

使用场景

  • 关联行为场景。需要注意的是,关联行为是可拆分的,而不是“组合”关系。

  • 事件多级触发场景。

  • 跨系统的消息交换场景,如消息队列的处理机制(ZooKeeper、Kafka 都是属于观察者)

  • 如某电子商务网站可以在执行发送操作后给用户多个发送商品打折信息,某团队战斗游戏中某队友牺牲将给所有成员提示等等,凡是涉及到一对一或者一对多的对象交互场景都可以使用观察者模式。

优点

  • 观察者和被观察者之间是抽象耦合

符合开闭原则,不管是增加观察者还是被观察者都很简单,对于支持抽象的语言实现起来更简单

  • 两者之间建立了触发机制

符合单一原则,每个类的职责是单一的,那么怎么把各个单一的职责串联成真实世界的复杂的逻辑关系呢?比如,我们去打猎,打死了一只母鹿,母鹿有三个幼崽,因失去了母鹿而饿死,尸体又被两只秃鹰争抢,因分配不均,秃鹰开始斗殴,然后羸弱的秃鹰死掉,生存下来的秃鹰,则因此扩大了地盘……这就是一个触发机制,形成了一个触发链。观察者模式可以完美地实现这里的链条形式。

缺点

效率问题,若一个被观察者同时被多个观察者观察,那么再被观察者发生改变时,需要通知很多个观察者。而且一些情况下,是按照观察者添加的顺序进行通知的,若没有异常处理,一个观察者被阻塞,那么其他将不会被通知到(这个时候可以考虑异步发送)。

注意事项

  • 广播链问题
    一个观察者可以有双重身份,即是观察者又是被观察者,这样逻辑上是没有问题的,但是实现后后期维护性较差,在设计模式之禅中提到,一个观察者模式中最多只出现一个对象既是观察者也是被观察者,也就是说消息最多转发一次(传递两次),这还是比较好控制的。
  • 异步通知问题
    在观察者较多的情况下被观察者状态改变后,通知到每一个观察者需要大量的时间,所以可以采用异步发送的方式。例如 ZooKeeper 就针对每个被观察的路径维护了一个单独的消息队列,客户端采用拉取的方式对产生的状态消息进行获取。还有许多例子也都是采用同样的方式实现。

具体实现

被观察者

//抽象目标
abstract class Subject {
    protected List<Observer> observers = new ArrayList<Observer>();

    //增加观察者方法
    public void add(Observer observer) {
        System.out.println(observer.getName()+"已经加入队列");
        observers.add(observer);
    }
    //删除观察者方法
    public void remove(Observer observer) {
        observers.remove(observer);
    }

    public abstract void notifyObserver(); //通知观察者方法
}

被观察者主要负责管理观察权限和观察者。

具体被观察者

//具体目标
class ConcreteSubject extends Subject {
    public void notifyObserver() {
        System.out.println("具体目标发生改变...");
        System.out.println("--------------");

        for (Object obs : observers) {
            ((Observer) obs).response();
        }

    }
}

抽象观察者

//抽象观察者
interface Observer {
    String getName();
    void response(); //反应
}

具体观察者1、2

//具体观察者1
class ConcreteObserver1 implements Observer {
    @Override
    public String getName() {
        return "ConcreteObserver1";
    }

    public void response() {
        System.out.println("ConcreteObserver1作出反应!");
    }
}

//具体观察者1
class ConcreteObserver2 implements Observer {
    @Override
    public String getName() {
        return "ConcreteObserver2";
    }

    public void response() {
        System.out.println("ConcreteObserver2作出反应!");
    }
}

调用者

public class ObserverPattern {
    public static void main(String[] args) {
        Subject subject = new ConcreteSubject();
        Observer obs1 = new ConcreteObserver1();
        Observer obs2 = new ConcreteObserver2();
        subject.add(obs1);
        subject.add(obs2);
        subject.notifyObserver();
    }
}

输出

ConcreteObserver1已经加入队列
ConcreteObserver2已经加入队列
具体目标发生改变...
--------------
ConcreteObserver1作出反应!
ConcreteObserver2作出反应!

模式扩展

  • 订阅发布模型

观察者模式也叫做发布/订阅模型(Publish/Subscribe),但准确来说订阅/发布模型可以说是观察模式的拓展或者变种。在标准的观察者模式中被观察者是可以管理观察者的,而这里说的订阅/发布模型中,消息发布者并不清楚自己被哪几个订阅者订阅了,它只需要将自身产生的消息发送出去(存储中介),而订阅者会时刻关注这个中介,以 pull 的方式来获取最新的消息。

主要差异:

  • 在观察者模式中,观察者是知道Subject的,Subject一直保持对观察者进行记录。然而,在发布订阅模式中,发布者和订阅者不知道对方的存在。它们只有通过消息代理进行通信。
  • 在观察者模式中对象是抽象耦合的,在发布订阅模式中,组件是松散耦合的。
  • 观察者模式标准模式下是同步的,被观察者同步通知他的观察者们,而发布订阅模型默认则是异步的。

总结

标准的设计模式多数情况下是为了更好的理解和学习,在实际实现中多多少少会有一点改变,这样即可以保持设计模式的优点,同时还能够简化实现或提升实用性。观察者模式也是如此,观察者模式本身很好理解,也很好实现,但我们见到的更多的是发布发布/订阅模型模型,而真正理解了观察者模式,再去理解发布/订阅模型就会简单很多。

参考

设计模式
设计模式之禅
3. 观察者模式 — Graphic Design Patterns

sev7e0
Write by sev7e0
end
本文目录