三种方式实现观察者模式 及 Spring中的事件编程模型

观察者模式可以说是众多设计模式中，最容易理解的设计模式之一了，观察者模式在Spring中也随处可见，面试的时候，面试官可能会问，嘿，你既然读过Spring源码，那你说说Spring中运用的设计模式吧，你可以自信的告诉他，Spring中的ApplicationListener就运用了观察者模式。

让我们一步一步来，首先我们要知道到底什么是观察者模式，用Java是如何实现的，在这里，我将会用三种方式来实现观察者模式。

什么是观察者模式

在现实生活中，观察者模式处处可见，比如

  • 看新闻，只要新闻开始播放了，就会把新闻推送给订阅了新闻的用户，在这里，新闻就是【被观察者】，而用户就是【观察者】。

  • 微信公众号，如果一个用户订阅了某个公众号，那么便会收到公众号发来的消息，那么，公众号就是【被观察者】，而用户就是【观察者】。

  • 热水器，假设热水器由三部分组成，热水器，警报器，显示器，热水器仅仅负责烧水，当水温到达设定的温度后，通知警报器，警报器发出警报，显示器也需要订阅热水器的烧水事件，从而获得水温，并显示。热水器就是【被观察者】，警报器，显示器就是【观察者】。

在这里，可以看到，【观察者】已经失去自主的权利，只能被动的接收来自【被观察者】的事件，无法主动观察。【观察者】成为了“受”，而【被观察者】成为了“攻”。【被观察者】只是通知【观察者】，不关心【观察者】收到通知后，会执行怎样的动作。

而在设计模式中，又把【被观察者】称为【主题】。

在观察者设计模式中，一般有四个角色：

  • 抽象主题角色（Subject）
  • 具体主题角色（ConcreteSubject）
  • 抽象观察者角色（Observer）
  • 具体观察者角色（ConcreteObserver）

其中，【主题】需要有一个列表字段，用来保存【观察者】的引用，提供两个方法（虚方法），即【删除观察者】【增加观察者】，还需要提供一个给客户端调用的方法，通知各个【观察者】：你们关心（订阅）的事件已经推送给你们了。

下面，我就用三种方式来实现观察者模式。

经典

public class News {
    private String title;
    private String content;

    public String getTitle() {
        return title;
    }

    public void setTitle(String title) {
        this.title = title;
    }

    public String getContent() {
        return content;
    }

    public void setContent(String content) {
        this.content = content;
    }
}

此类不属于观察者模式必须的类，用来存放事件的信息。

public interface Subject {
    List<People> peopleList = new ArrayList<>();

    default void add(People people) {
        peopleList.add(people);
    }

    default void remove(People people) {
        peopleList.remove(people);
    }

    void update();
}

抽象主题角色，在这个角色中，有一个字段peopleList，用来保存【观察者】的引用，同时定义了两个接口，这是Java8默认接口实现的写法。这两个接口是给客户端调用的，用来【删除观察者】【增加观察者】，还提供一个方法，此方法需要被【具体主题角色】重写，用来通知各个【观察者】。

public class NewsSubject implements Subject{
    public void update() {
        for (People people : peopleList) {
            News news = new News();
            news.setContent("今日在大街上，有人躲在草丛中袭击路人，还大喊“德玛西亚万岁”");
            news.setTitle("德玛西亚出现了");
            people.update(news);
        }
    }
}

具体主题角色，重写了【抽象主题角色】的方法，循环列表，通知各个【观察者】。

public interface People {
    void update(News news);
}

抽象观察者角色，定义了一个接口，【具体观察者角色】需要重写这个方法。

下面就是【具体观察者角色】了：

public class PeopleA implements People {
    @Override
    public void update(News news) {
        System.out.println("这个新闻真好看");
    }
}

public class PeopleB implements People {
    @Override
    public void update(News news) {
        System.out.println("这个新闻真无语");
    }
}

public class PeopleC implements People {
    @Override
    public void update(News news) {
        System.out.println("这个新闻真逗");
    }
}

客户端：

public class Main {
    public static void main(String[] args) {
        Subject subject = new NewsSubject();
        subject.add(new PeopleA());
        subject.add(new PeopleB());
        subject.add(new PeopleC());
        subject.update();
    }
}

运行：


image.png

我们学习设计模式，必须知道设计模式的优缺点，那么观察者设计模式的优缺点是什么呢？

优点：

  • 【主题】和【观察者】通过抽象，建立了一个松耦合的关系，【主题】只知道当前有哪些【观察者】，并且发送通知，但是不知道【观察者】具体会执行怎样的动作。这也很好理解，比如 微信公众号推送了一个消息过来，它不知道你会采取如何的动作，是 微笑的打开，还是愤怒的打开，或者是直接把消息删了，又或者把手机扔到洗衣机洗刷刷。

  • 符合开闭原则，如果需要新增一个【观察者】，只需要写一个类去实现【抽象观察者角色】即可，不需要改动原来的代码。

缺点：

  • 客户端必须知道所有的【观察者】，并且进行【增加观察者】和【删除观察者】的操作。

  • 如果有很多【观察者】，那么所有的【观察者】收到通知，可能需要花费很久时间。

当然以上优缺点，是最直观的，可以很容易理解，并且体会到的。其他优缺点，可以自行百度。

Lambda

在介绍这种写法之前，有必要介绍下函数式接口，函数式接口的概念由来已久，一般来说只定义了一个虚方法的接口就叫函数式接口，在Java8中，由于Lambda表达式的出现，让函数式接口大放异彩。

我们仅仅需要修改客户端的代码就可以：

    public static void main(String[] args) {
        Subject subject = new NewsSubject();
        subject.add(a -> System.out.println("已阅这新闻"));
        subject.add(a -> System.out.println("假的吧"));
        subject.add(a -> System.out.println("昨天就看过了"));
        subject.update();
    }

运行结果：


image.png

利用Lambda表达式和函数式接口，可以省去【具体观察者角色】的定义，但是个人认为，这并非属于严格意义上的观察者模式，而且弊端很明显：

  • 客户端需要知道观察者的具体实现。
  • 如果观察者的具体实现比较复杂，可能代码并没有那么清晰。

所以这种写法，具有一定的局限性。

借用大神的一句话

设计模式的出现，是为了弥补语言的缺陷。

正是由于语言的升级，让某些设计模式发生了一定的变化，除了观察者模式，还有模板方法模式、责任链模式等，都由于 Lambda表达式的出现，而出现了一些变化。

JDK

在Java中，本身就提供了一个接口：Observer，一个子类：Observable，其中Observer表示【观察者】，Observable表示【主题】，可以利用这两个子类和接口来实现观察者模式：

public class NewsObservable extends Observable {
    public void update() {
       setChanged();
       notifyObservers();
    }
}

public class People1 implements Observer {
    @Override
    public void update(Observable o, Object arg) {
        System.out.println("小编真无聊");
    }
}

public class People2 implements Observer {
    @Override
    public void update(Observable o, Object arg) {
        System.out.println("开局一张图，内容全靠编");
    }
}

客户端：

  public static void main(String[] args) {
        NewsObservable newsObservable = new NewsObservable();
        newsObservable.addObserver(new People1());
        newsObservable.addObserver(new People2());
        newsObservable.update();
    }

运行结果：


image.png

在这里，我不打算详细介绍这种实现方式，因为从Java9开始，Java已经不推荐这种写法了，而推荐用消息队列来实现。是不是很开心，找到一个借口不去研究Observable，Observer 这两个东西了。

Spring中的事件编程模型

Spring中的事件编程模型就是观察者模式的实现，SpringBoot就利用了Spring的事件编程模型来完成一些操作，这里暂时不表。

在Spring中定义了一个ApplicationListener接口，从名字就知道它是一个监听器，是监听Application的事件的，那么Application又是什么，就是ApplicationContext，ApplicationContext内置了几个事件，其中比较容易理解的是：

  • ContextRefreshedEvent
  • ContextStartedEvent
  • ContextStoppedEvent
  • ContextClosedEvent
    从名称上来看，就知道这几个事件是什么时候被触发的了。

下面我演示下具体的用法，比如我想监听ContextRefreshedEvent事件，如果事件发生了，就打印一句话。

@Component
public class MyListener implements ApplicationListener{
    @Override
    public void onApplicationEvent(ApplicationEvent applicationEvent) {
        if(applicationEvent  instanceof ContextRefreshedEvent){
            System.out.println("刷新了");
        }
    }
}

@Configuration
@ComponentScan
public class AppConfig {
}

    public static void main(String[] args) {
        AnnotationConfigApplicationContext context=new AnnotationConfigApplicationContext(AppConfig.class);
    }

运行结果：


image.png

当时学习Spring，看到Spring提供了各式各样的接口来让程序员们对Spring进行扩展，并且没有任何侵入性，我不得不佩服Spring的开发者们。这里也是，我们可以看到在客户端找不到任何关于“订阅事件”的影子。

这种实现方式不是太好，可以看到我们在方法内部做了一个判断：接收到的事件是否为ContextRefreshedEvent。

伟大的Spring还提供了泛型的ApplicationListener，我们可以通过泛型的ApplicationListener来完善上面的代码：

@Component
public class MyListener implements ApplicationListener<ContextRefreshedEvent> {
    @Override
    public void onApplicationEvent(ContextRefreshedEvent event) {
        System.out.println("刷新了");
    }
}

我们还可以利用Spring中的事件编程模型来自定义事件，并且发布事件：

首先，我们需要定义一个事件，来实现ApplicationEvent接口，代表这是一个Application事件，其实上面所说的四个内置的事件也实现了ApplicationEvent接口：

public class MyEvent extends ApplicationEvent {
    public MyEvent(Object source) {
        super(source);
    }
}

还需要定义一个监听器，当然，在这里需要监听MyEvent事件：

@Component
public class MyListener implements ApplicationListener<MyEvent> {
    @Override
    public void onApplicationEvent(MyEvent event) {
        System.out.println("我订阅的事件已经到达");
    }
}

现在有了事件，也有了监听器，是不是还少了发布者，不然谁去发布事件呢？

@Component
public class MyEventPublish implements ApplicationEventPublisherAware {

    private ApplicationEventPublisher publisher;

    @Override
    public void setApplicationEventPublisher(ApplicationEventPublisher applicationEventPublisher) {
        this.publisher = applicationEventPublisher;
    }

    public void publish(Object obj) {
        this.publisher.publishEvent(obj);
    }
}

发布者，需要实现ApplicationEventPublisherAware 接口，重写publish方法，顾名思义，这就是发布方法，那么方法的参数obj是干嘛的呢，作为发布者，应该需要知道我要发布什么事件，以及事件来源（是谁触发的）把，这个obj就是用来存放这样的数据的，当然，这个参数需要我们手动传入进去。setApplicationEventPublisher是Spring内部主动调用的，可以简单的理解为初始化发布者。

现在就剩最后一个角色了，监听器有了，发布者有了，事件也有了，对，没错，还少一个触发者，毕竟要有触发者去触发事件啊：

@Component
public class Service {

    @Autowired
    private  MyEventPublish publish;

    public void publish() {
        publish.publish(new MyEvent(this));
    }
}

其中publish方法就是给客户端调用的，用来触发事件，可以很清楚的看到传入了new MyEvent(this)，这样发布者就可以知道我要触发什么事件和是谁触发了事件。

当然，还需要把一切交给Spring管理：

@Configuration
@ComponentScan
public class AppConfig {
}

客户端：

    public static void main(String[] args) {
        AnnotationConfigApplicationContext context=new AnnotationConfigApplicationContext(AppConfig.class);
        context.getBean(Service.class).publish();;
    }

运行结果：


image.png

这一篇博客比较简单，只是简单的应用，但是只有会了应用，才能谈源码。

这篇博客到这里就结束了，谢谢大家。

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 201,784评论 5赞 474
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 84,745评论 2赞 378
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 148,702评论 0赞 335
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,229评论 1赞 272
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,245评论 5赞 363
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,376评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,798评论 3赞 393
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,471评论 0赞 256
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,655评论 1赞 295
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,485评论 2赞 318
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,535评论 1赞 329
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,235评论 3赞 318
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,793评论 3赞 304
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,863评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,096评论 1赞 258
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 42,654评论 2赞 348
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,233评论 2赞 341