看了西游记,你可知道孙悟空是如何召唤土地的吗?

简介: 看了西游记,你可知道孙悟空是如何召唤土地的吗?

                                                                                                   

小时候最开心的事莫过于躺在沙发上看《西游记》了。大闹天宫、三打白骨精、真假美猴王......一幕幕精彩的故事萦绕脑海,现在想来,回味无穷。

不知道你有没有注意到这个细节:每当孙悟空到了一个新的环境需要了解本地的“风土人情”时,都会挥舞一下金箍棒,将土地召唤出来。那么你可知道,土地公公接收孙悟空召唤的原理是什么吗?

事件通知机制

我们可以先将其理解为“事件通知机制”,即每当孙悟空将金箍棒敲在地上时,就相当于给土地发了一封 email 的通知,告诉他俺老孙来了,赶快出来接驾。当土地收到通知之后就会立即现身了。

大家都知道 Spring 已经为我们提供好了事件监听、订阅的实现,接下来我们用代码来实现一下这个场景。

首先我们要定义一个事件,来记录下孙悟空敲地的动作。

@Getter
public class MonkeyKingEvent extends ApplicationEvent {
    private MonkeyKing monkeyKing;
    public MonkeyKingEvent(MonkeyKing monkeyKing) {
        super("monkeyKing");
        this.monkeyKing = monkeyKing;
    }
}

其中 MonkeyKing 是我们定义好的孙悟空的实体类

@Data
public class MonkeyKing {
    /**
     * 是否敲地,默认为否
     **/
    private boolean knockGround = false;
}

然后我们需要实现 ApplicationListener 来监听孙悟空敲地的动作。

@Component
public class MyGuardianListener implements ApplicationListener<MonkeyKingEvent> {
    @Override
    public void onApplicationEvent(MonkeyKingEvent event) {
        boolean knockGround = event.getMonkeyKing().isKnockGround();
        if(knockGround){
            MyGuardian.appear();
        }else{
            MyGuardian.seclusion();
        }
    }
}

最后我们来验证下整个流程。

@PostMapping
public void testEvent(@RequestParam boolean knockGround) {
    MonkeyKing monkeyKing = new MonkeyKing();
    monkeyKing.setKnockGround(knockGround);
    MonkeyKingEvent monkeyKingEvent = new MonkeyKingEvent(monkeyKing);
    //发布孙悟空敲地的动作事件
    applicationEventPublisher.publishEvent(monkeyKingEvent);
}

当我们调用testEvent()方法传入knockGroundtrue 时,打印

土地公公出现了

传入为false时,打印

土地公公遁地了

这样我们就简单实现了“孙悟空召唤土地”的功能。你以为这样就结束了?从小老师就教导我们要“知其然,更要知其所以然”。

大家都说读源码更像是在喝咖啡,读不懂又苦又涩,读懂了浓郁醇香。为了不影响大家的好心情,这里我们就不研究它的源码了,我们直捣黄龙。

观察者模式

说是事件通知机制也好,事件监听-订阅的实现也罢,其实它内部的最终实现原理依赖的是观察者模式。看到这,先不要胆怯,不要觉得设计模式晦涩难懂、久攻不下。今天我就用通俗易懂的小故事来带你重新认识一下观察者模式。

故事是这样的,上边我们只说了孙悟空敲地的动作,但是你是否还记得孙悟空将金箍棒往天上一指,便换来雷公电母、龙王等为其施法布雨?闭上双眼,与虎力大仙比试的场景仍历历在目。

由此可见,不光土地能收到孙悟空的通知,连雷公电母和龙王也是可以接收到的。在这里,我们把孙悟空比作主题,也就是大家说的被观察者和 Subject的概念,把雷公电母和龙王以及土地比作观察者。

以下是我们的代码逻辑:

首先,我们定义一个主题的基础类,里边会记录所有订阅该主题的观察者列表,还包含了增加、删除以及通知观察者的方法。

public class Subject {
    //观察者列表
    private Vector<Observer> vector = new Vector();
    /**
     * 增加观察者
     **/
    public void addObserver(Observer observer){
        vector.add(observer);
    }
    /**
     *  删除观察者
     **/
    public void deleteObserver(Observer observer){
        vector.remove(observer);
    }
    /**
     *  通知所有观察者
     **/
    public void notifyObserver(String goldenCudgel) {
        for(Observer observer : vector) {
             observer.update(goldenCudgel);
         }
    }
}

然后,我们定义一个观察者的接口,包含观察者收到通知之后的“动作”。

public interface Observer {
    void update(String goldenCudgel);
}

这时候我们再分别定义出“土地”、“雷公电母”、“龙王”的观察者实体类,实现具体的打雷下雨等动作。

“雷公电母”、“龙王”等实现与“土地”类似,故此处仅展示观察者“土地”。

@Component
public class MyGuardianObserver implements Observer {
    @Override
    public void update(String goldenCudgel) {
        if(upGoldenCudgel(goldenCudgel)) {
            System.out.println("土地公公出现了");
        }
    }
    public boolean upGoldenCudgel(String goldenCudgel){
        if(Objects.equals(goldenCudgel,"down")){
            return true;
        }
        return false;
    }
}

接着,我们就可以定义被观察者的具体实现类“孙悟空”了

public class MonkeyKingSubject extends Subject{
    /**
     * 金箍棒是举起来还是放下呢?哈哈,你猜猜。。。
     **/
    public void doGoldenCudgel(String goldenCudgel){
        notifyObserver(goldenCudgel);
    }
}

最后我们来做个测试看看他们能不能响应孙悟空的通知。

@PostMapping
public void observerTest(){
    MonkeyKingSubject subject = new MonkeyKingSubject();
    subject.addObserver(new ThunderGodObserver());
    subject.addObserver(new MyGuardianObserver());
    subject.addObserver(new DragonKingObserver());
    subject.doGoldenCudgel("up");
    System.out.println("我是分割线-----------------------------");
    subject.doGoldenCudgel("down");
}

结果展示

雷公电母发出电闪雷鸣
龙王前来下雨
我是分割线-----------------------------
土地公公出现了

总结

故事的最后怎么能少的了总结呢?观察者模式与事件通知机制都是在一对多的关系中,当一个对象被修改时,则会自动通知依赖它的对象,两者之间相互独立,互相解耦,这样既省去了反复检索状态的资源消耗,也能够得到最高的反馈速度。

当然它的缺点也不容忽视:

  1. 如果一个被观察者对象有很多的直接和间接的观察者的话,将所有的观察者都通知到会花费很多时间;
  2. 如果在观察者和观察目标之间有循环依赖的话,观察目标会触发它们之间进行循环调用,可能导致系统崩溃;
  3. 观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的,而仅仅只是知道观察目标发生了变化;

文章的最后,照例奉上源码,后台回复 event 即可获取。以上就是今天的全部内容了,如果你有不同的意见或者更好的idea,欢迎联系阿Q,添加阿Q可以加入技术交流群参与讨论呦!


相关文章
|
消息中间件 存储 算法
深度解析Kafka中的消息奥秘
深度解析Kafka中的消息奥秘
478 0
|
机器学习/深度学习 数据采集 人工智能
深度学习之稳健的模型推理与不确定性建模
基于深度学习的稳健模型推理与不确定性建模,是现代AI系统中至关重要的研究方向。随着深度学习在各类应用中的成功,如何保证模型在面对未知或不确定性输入时仍能做出稳健的推理,并能够量化这种不确定性,成为关键问题。稳健性与不确定性建模可以提高模型的安全性、可靠性,尤其在自动驾驶、医疗诊断等高风险领域。
759 0
|
存储 数据可视化 项目管理
RNA-seq 差异分析的细节详解 (5)
RNA-seq 差异分析的细节详解 (5)
RNA-seq 差异分析的细节详解 (5)
|
机器学习/深度学习 Python
【10月更文挑战第5天】「Mac上学Python 6」入门篇6 - 安装与使用Anaconda
本篇将详细介绍如何在Mac系统上安装和配置Anaconda,如何创建虚拟环境,并学习如何使用 `pip` 和 `conda` 管理Python包,直到成功运行第一个Python程序。通过本篇,您将学会如何高效地使用Anaconda创建和管理虚拟环境,并使用Python开发。
533 4
【10月更文挑战第5天】「Mac上学Python 6」入门篇6 - 安装与使用Anaconda
|
移动开发 前端开发 Java
过时的Java技术盘点:避免在这些领域浪费时间
【10月更文挑战第14天】 在快速发展的Java生态系统中,新技术层出不穷,而一些旧技术则逐渐被淘汰。对于Java开发者来说,了解哪些技术已经过时是至关重要的,这可以帮助他们避免在这些领域浪费时间,并将精力集中在更有前景的技术上。本文将盘点一些已经或即将被淘汰的Java技术,为开发者提供指导。
662 7
|
机器学习/深度学习 自然语言处理 并行计算
深度学习笔记(十四):Transormer知识总结
关于深度学习中Transformer模型的知识总结,涵盖了Self-attention机制、QKV、Multi-head attention、位置编码和并行运算等关键概念,以及如何在PyTorch中实现Self-attention。
322 1
|
存储 编解码 边缘计算
从RTMPS到MPEG-DASH:直播带货背后的秘密流程
大家好,我是小米,今天聊聊“社区直播带货”的技术流程。文章介绍了RTMPS协议的安全可靠传输,MPEG-DASH的自适应比特率流媒体技术,以及直播数据如何通过边缘节点和数据中心进行高效处理与分发,确保用户流畅观看。通过这些技术,直播带货不仅画质清晰,还保障了安全性和用户体验。希望本文能帮助你深入了解这一流程。如果有任何问题,欢迎留言讨论!
283 2
|
弹性计算 JSON API
一键云部署:资源编排 ROS 轻松部署文本转语音系统 ChatTTS
ChatTTS是一款针对对话场景的文本转语音模型,支持英中两种语言,训练数据超过10万小时。ChatTTS可通过WebUI和API访问。阿里云的资源编排服务(ROS)提供了一键部署ChatTTS到云端的方案,用户只需在ROS控制台配置模板参数,如区域和实例类型,即可完成部署。部署后,从资源栈输出获取ChatTTS服务地址。ROS利用IaC理念自动化部署云资源和应用,提高了部署效率和稳定性。
一键云部署:资源编排 ROS 轻松部署文本转语音系统 ChatTTS
|
Kubernetes 数据可视化 Java
|
监控 数据可视化 Go
实战 | Telegraf+ InfluxDB+Grafana 搭建服务器性能监控平台
在之前的文章《移动端UI自动化过程中的难点及应对策略》中我们讨论了影响移动端自动化稳定性的一些因素,其中宿主机环境是一个不可忽视的问题,大家都知道移动端的自动化一般都需要将设备挂载到实体服务器上运行,如果服务器宿主机出现断网或者磁盘空间不足等情况,都会在一定程度上影响自动化任务的执行,因此今天跟大家分享一下如何做服务器宿主机的监控。
806 0
实战 | Telegraf+ InfluxDB+Grafana 搭建服务器性能监控平台

热门文章

最新文章