当前位置: 首页 > article >正文

设计模式——观察者设计模式(行为型)

摘要

本文详细介绍了观察者设计模式,包括其定义、结构、实现方式、适用场景以及实战示例。通过代码示例展示了如何在Spring框架下实现观察者模式,以及如何通过该模式实现状态变化通知。同时,对比了观察者模式与消息中间件在设计理念、耦合程度、通信方式和分布式支持等方面的差异,帮助读者更好地理解和选择合适的实现方式。

1. 观察者设计模式定义

观察者设计模式(Observer Pattern)是一种行为型设计模式,定义了一种一对多的依赖关系,使得当一个对象(被观察者)的状态发生改变时,所有依赖它的对象(观察者)都会得到自动通知并更新,从而实现对象间的松耦合和实时通讯。观察者模式通过定义对象间的发布-订阅关系,实现事件的自动通知和响应,适合事件驱动和异步消息场景。

1.1. 核心定义

角色

  • 被观察者(Subject):维护一组观察者,负责状态的管理和通知。
  • 观察者(Observer):注册到被观察者,一旦被观察者状态变化,接收通知并执行相应动作。

目的:让多个观察者对象自动获得被观察者的状态变化,降低对象间耦合度。

2. 观察者设计模式结构

观察者模式包含如下角色:

  • Subject: 目标
  • ConcreteSubject: 具体目标
  • Observer: 观察者
  • ConcreteObserver: 具体观察者

2.1. 观察者模式类图

2.2. 观察者模式时序图

3. 观察者设计模式实现方式

3.1. 观察者设计模式实现步骤

3.1.1. 定义抽象主题(Subject)接口

  • 提供注册、移除和通知观察者的方法。
public interface Subject {void registerObserver(Observer observer);void removeObserver(Observer observer);void notifyObservers();
}

3.1.2. 定义抽象观察者(Observer)接口

  • 声明一个更新方法,主题状态变化时调用。
public interface Observer {void update(String message);
}

3.1.3. 具体主题类实现 Subject

  • 维护观察者列表,实现注册、移除、通知逻辑。
  • 当自身状态变化时调用 notifyObservers(),遍历通知所有观察者。
import java.util.ArrayList;
import java.util.List;public class ConcreteSubject implements Subject {private final List<Observer> observers = new ArrayList<>();private String state;@Overridepublic void registerObserver(Observer observer) {observers.add(observer);}@Overridepublic void removeObserver(Observer observer) {observers.remove(observer);}@Overridepublic void notifyObservers() {for (Observer observer : observers) {observer.update(state);}}public void setState(String state) {this.state = state;notifyObservers();}
}

3.1.4. 具体观察者实现 Observer

  • 实现 update 方法,接收通知并做出响应。
public class ConcreteObserver implements Observer {private String name;public ConcreteObserver(String name) {this.name = name;}@Overridepublic void update(String message) {System.out.println(name + " 收到通知,状态变为: " + message);}
}

3.2. 观察者测试示例

public class ObserverPatternDemo {public static void main(String[] args) {ConcreteSubject subject = new ConcreteSubject();Observer observer1 = new ConcreteObserver("观察者1");Observer observer2 = new ConcreteObserver("观察者2");subject.registerObserver(observer1);subject.registerObserver(observer2);subject.setState("状态1");subject.setState("状态2");}
}

说明

  • 主题(Subject)维护观察者集合,状态变化时通知所有观察者。
  • 观察者实现更新接口,获得主题最新状态。

4. 观察者设计模式适合场景

4.1. ✅ 适合使用观察者设计模式的场景

适合场景

说明

事件驱动系统

事件产生后需要通知多个模块或对象做出响应,如 UI 事件监听、消息推送。

一对多依赖关系

一个对象状态变化需要通知多个依赖对象,如股票价格更新通知所有订阅者。

松耦合需求

希望对象间解耦,观察者与被观察者不直接依赖,实现灵活扩展。

广播通信

需要将消息广播给多个接收者,且接收者可动态增加和移除。

异步通知

状态更新后,通知观察者进行异步处理。

分布式系统

多个服务或模块之间的状态同步与消息推送。

4.2. ❌ 不适合使用观察者设计模式的场景

不适合场景

说明

对象之间不存在依赖关系

彼此独立的对象无需相互通知。

通知对象数量固定且简单

只有少数固定对象,且耦合关系明确,使用简单调用即可。

需要严格同步控制的场景

观察者通知是异步的,无法满足严格同步时序需求。

性能敏感场景

大量观察者通知导致性能开销大,影响系统响应速度。

过度使用导致复杂性增加

观察者链条过长,维护困难,代码难以理解。

总结:观察者模式主要适用于需要“自动广播状态变化给多个对象”且“希望对象间低耦合”的场景。不适合简单调用、同步严格或性能瓶颈明显的场景。

5. 观察者设计模式实战示例

5.1. 场景说明

在风控系统中,当订单状态发生变化(比如风控审核结果出来后),需要通知多个模块(比如日志记录模块、报警模块、缓存更新模块)来响应该状态变化。

5.2. 定义观察者接口

public interface OrderStatusObserver {void update(String orderId, String status);
}

5.3. 定义具体观察者实现类

import org.springframework.stereotype.Component;@Component
public class LoggingObserver implements OrderStatusObserver {@Overridepublic void update(String orderId, String status) {System.out.println("日志模块:订单 " + orderId + " 状态更新为:" + status);// 这里可以写日志持久化操作}
}@Component
public class AlertObserver implements OrderStatusObserver {@Overridepublic void update(String orderId, String status) {if ("REJECTED".equals(status)) {System.out.println("报警模块:订单 " + orderId + " 审核拒绝,触发报警!");// 触发报警逻辑}}
}@Component
public class CacheObserver implements OrderStatusObserver {@Overridepublic void update(String orderId, String status) {System.out.println("缓存模块:更新订单 " + orderId + " 状态缓存为:" + status);// 缓存刷新逻辑}
}

5.4. 定义主题接口和实现类

public interface OrderStatusSubject {void registerObserver(OrderStatusObserver observer);void removeObserver(OrderStatusObserver observer);void notifyObservers(String orderId, String status);
}
import org.springframework.stereotype.Component;import javax.annotation.PostConstruct;
import java.util.ArrayList;
import java.util.List;@Component
public class OrderStatusSubjectImpl implements OrderStatusSubject {private final List<OrderStatusObserver> observers = new ArrayList<>();// 使用Spring自动注入所有实现了OrderStatusObserver接口的Bean@Autowiredprivate List<OrderStatusObserver> observerBeans;@PostConstructpublic void init() {// 初始化时,将所有观察者注册进列表observers.addAll(observerBeans);}@Overridepublic void registerObserver(OrderStatusObserver observer) {observers.add(observer);}@Overridepublic void removeObserver(OrderStatusObserver observer) {observers.remove(observer);}@Overridepublic void notifyObservers(String orderId, String status) {for (OrderStatusObserver observer : observers) {observer.update(orderId, status);}}
}

5.5. 4. 业务调用示例(比如风控服务)

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;@Service
public class RiskControlService {@Autowiredprivate OrderStatusSubject orderStatusSubject;public void auditOrder(String orderId, boolean passed) {// 风控业务逻辑String status = passed ? "APPROVED" : "REJECTED";System.out.println("风控审核完成,订单:" + orderId + ",状态:" + status);// 审核完成后,通知所有观察者orderStatusSubject.notifyObservers(orderId, status);}
}

5.6. 测试Controller(可选)

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;@RestController
public class RiskController {@Autowiredprivate RiskControlService riskControlService;@PostMapping("/auditOrder")public String auditOrder(@RequestParam String orderId, @RequestParam boolean passed) {riskControlService.auditOrder(orderId, passed);return "审核完成";}
}

5.7. 实战示例总结

  • 观察者接口 OrderStatusObserver,多个实现类由Spring管理并注入。
  • 主题 OrderStatusSubjectImpl 维护观察者列表,利用 @Autowired 自动注入所有观察者Bean。
  • 风控业务执行后调用主题的 notifyObservers(),实现状态变化通知。
  • 全部采用Spring注解管理,未用构造函数注入,代码简洁且易于扩展。

6. 观察者设计模式思考

6.1. 观察着模式和使用消息中间件来通知处理的方式有什么不同?

很好的问题!观察者模式和消息中间件在实现“发布-订阅”或通知机制时都很常用,但它们的设计理念、实现方式和适用场景有显著差别。下面帮你详细分析两者的区别:

维度

观察者模式

消息中间件(如Kafka、RabbitMQ、ActiveMQ等)

设计层次

设计模式,属于应用内部的设计范式,通常是在代码内部直接实现。

独立的中间件系统,属于基础设施层,提供异步消息传递机制。

耦合程度

被观察者和观察者耦合较紧密,观察者必须知道被观察者实例(尽管解耦设计可以降低耦合)。

发布者和订阅者完全解耦,彼此不直接依赖,只通过消息中间件通信。

通信方式

通常是同步调用,状态变化时立即调用观察者的更新方法。

典型异步通信,消息发送后,接收方异步消费,支持异步处理和缓冲。

分布式支持

一般用于单体应用或同一JVM内对象之间的通知。

天生支持分布式系统,跨进程、跨服务器,甚至跨数据中心的消息传递。

扩展性

观察者数量有限,扩展时需要修改代码或依赖注入配置。

高度扩展,支持大量消费者和复杂路由规则,方便动态添加消费者。

容错与持久化

无持久化和容错机制,一旦通知失败可能丢失信息。

支持消息持久化、重试、消息确认、死信队列,增强系统可靠性。

性能影响

观察者调用是同步的,影响调用链的执行时间,可能导致性能瓶颈。

异步处理,解耦主业务流程,提升系统吞吐量和响应速度。

使用场景

小型系统、UI事件响应、简单状态同步、模块内部事件通知。

大型分布式系统、微服务间异步通信、异步任务调度、事件驱动架构。

6.1.1. 简单总结:

  • 观察者模式 适合应用内、轻量级的同步通知,设计简单,适合对象之间状态变化通知。
  • 消息中间件 适合跨进程、跨网络、异步且高可靠的消息通信,适合分布式系统异步解耦和复杂事件流转。

6.1.2. 举例对比:

  • 观察者模式:风控模块风控结果出来后,同步通知日志模块和报警模块,立即处理。
  • 消息中间件:风控模块发布“风控结果”消息到消息队列,日志模块和报警模块异步订阅该消息,消息队列保证消息可靠送达和解耦。

博文参考

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

http://www.lryc.cn/news/2396313.html

相关文章:

  • 【前端】Vue中使用CKeditor作为富文本编辑器
  • CSS篇-6
  • 【计算机系统结构】习题2
  • 用户资产化视角下开源AI智能名片链动2+1模式S2B2C商城小程序的应用研究
  • day023-面试题总结
  • 机器学习实验七--SVM垃圾邮件分类器
  • C++23 std::fstreams基础回顾
  • Git初识Git安装
  • 使用Redisson实现分布式锁发现的【订阅超时】Subscribe timeout: (7500ms)
  • 数据分析的方法总结
  • 如何使用 poetry 创建虚拟环境,VSCode 如何激活使用 Poetry 虚拟环境(VSCode如何配置 Poetry 虚拟环境)
  • 每天掌握一个Linux命令 - ps
  • 牛客小白月赛117
  • 浅谈 Linux 文件覆盖机制
  • 美化显示GDB调试的数据结构
  • 一篇学习CSS的笔记
  • Rust 学习笔记:自定义构建和发布配置
  • StarRocks x Iceberg:云原生湖仓分析技术揭秘与最佳实践
  • 笔试笔记(运维)
  • JVM——云原生时代JVM的演进之路
  • 使用langchain实现五种分块策略:语义分块、父文档分块、递归分块、特殊格式、固定长度分块
  • 【项目记录】登录认证(下)
  • Debian上安装PostgreSQL的故障和排除
  • linux文件管理(补充)
  • Python训练营---Day42
  • 基于空天地一体化网络的通信系统matlab性能分析
  • c++ opencv 形态学操作腐蚀和膨胀
  • Axure组件即拖即用:横向拖动菜单(支持左右拖动选中交互)
  • Hadoop MapReduce:大数据处理利器
  • RabbitMQ-Go 性能分析