「这是我参与2022首次更文挑战的第2天,活动详情查看:2022首次更文挑战」。
上文我们讲解了事件通知机制,本文让我们直捣黄龙,来看一下观察者模式的实现!
观察者模式
说是事件通知机制也好,事件监听-订阅的实现也罢,其实它内部的最终实现原理依赖的是观察者模式。看到这,先不要胆怯,不要觉得设计模式晦涩难懂、久攻不下。今天我就用通俗易懂的小故事来带你重新认识一下观察者模式。
故事是这样的,上边我们只说了孙悟空敲地的动作,但是你是否还记得孙悟空将金箍棒往天上一指,便换来雷公电母、龙王等为其施法布雨?闭上双眼,与虎力大仙比试的场景仍历历在目。
由此可见,不光土地能收到孙悟空的通知,连雷公电母和龙王也是可以接收到的。在这里,我们把孙悟空比作主题,也就是大家说的被观察者和 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");
}
复制代码
结果展示
雷公电母发出电闪雷鸣
龙王前来下雨
我是分割线-----------------------------
土地公公出现了
复制代码
总结
故事的最后怎么能少的了总结呢?观察者模式与事件通知机制都是在一对多的关系中,当一个对象被修改时,则会自动通知依赖它的对象,两者之间相互独立,互相解耦,这样既省去了反复检索状态的资源消耗,也能够得到最高的反馈速度。
当然它的缺点也不容忽视:
- 如果一个被观察者对象有很多的直接和间接的观察者的话,将所有的观察者都通知到会花费很多时间;
- 如果在观察者和观察目标之间有循环依赖的话,观察目标会触发它们之间进行循环调用,可能导致系统崩溃;
- 观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的,而仅仅只是知道观察目标发生了变化;
文章的最后,照例奉上源码,后台回复 event
即可获取。以上就是今天的全部内容了,如果你有不同的意见或者更好的idea
,欢迎联系阿Q,添加阿Q可以加入技术交流群参与讨论呦!