《Head.First设计模式》的学习笔记(3)--观察者模式
意图:定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。
结构:
例子:
下面以模拟气象站系统来加以说明。
需求分析:
该系统的需求如下:
1、气象站能够追踪目前的天气状况,包括温度、湿度、气压、
2、气象站能够提供三种布告板,分别显示目前天气状况、气象统计和简单的预报。
3、布告板上的数据必须实时更新。
4、气象站必须提供一组API,供其他开发人员开发其他的布告板。
设计部分:
基于以上需求,该系统可以设计成3部分:气象站(获取实际气象数据的物理装置)、WeatherData对象(追踪来自气象站的数据,并更新布告板)和布告板(显示目前的天气状况给用户看)。效果图如下:
错误的类图设计(即没有学过设计模式时的第一感觉)可能如下:
相应的代码实现部分:

2

3

4

5

6

7

8

9

10

这个类图设计的缺点:
1)、该设计是针对具体实现编程,而非针对接口。
2)、对于每个新的布告板,我们都得修改代码。
3)、我们无法在运动时动态得增加或删除布告板。
4)、我们尚未封装改变的部分。
那么如何改正这些缺点呢?
首先我们必须明白这些缺点的根源在哪里。很明显,我们在类图设计时依赖关系错了,应该依赖倒置。CurrrentConditionsDisplay类、StatisticsDisplay类和ForcastDisplay类应该依赖WeatherData类,而不是相反,这样就可以起到解耦的目的。
其次,CurrrentConditionsDisplay类、StatisticsDisplay类和ForcastDisplay类都有一个Update()方法,因此应该提炼一个接口,这样可以实现“针对接口编程”,使代码更加灵活,也方便其他开发人员开发其他的布告板。
进一步思考:
1)、改正这些缺点后,我们的类图已经与观察者模式的结构有点类似了。
2)、我们的气象站系统的最大问题其实就是一对多的依赖引起的,而观察者模式正是解除一对多关系的不二法门,因此我们有必要采用观察者模式。
采用了观察者模式后设计的类图应该是这样:
WeatherDatea实现ISubject接口,CurrentConditionsDisplay、ForcastDisplay、StatisticsDisplay实现IObserver接口,ISubject调用IObserver,CurrentConditionsDisplay、ForcastDisplay、StatisticsDisplay调用ISubject。
相应的代码实现部分:

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
· Manus爆火,是硬核还是营销?
· 终于写完轮子一部分:tcp代理 了,记录一下
· 别再用vector<bool>了!Google高级工程师:这可能是STL最大的设计失误
· 单元测试从入门到精通