观察者模式——设计模式_李建忠 设计模式 动机 作用 定义

本文根据设计模式学习视频编写
李建忠-23个设计模式

0 归属组件协作模式

 现代软件专业分工之后的第一个结果是“框架与应用程序的划分”，“组件协作”模式通过晚期绑定，来实现框架与应用程序之间的松耦合，是二者之间协作时常用的模式。
 典型模式
• Template Method
• Observer / Event
• Strategy

1 动机（Motivation）

在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系” ——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。
使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。

例：文件分割器。将一个大文件分割成多个小文件，显示分割进度条。
方法一：要显示进度条，在界面上添加一个进度条ProgressBar* m_progressBar，然后传给FileSplitter，在方法split()中更新进度条。
该方法违反了面向对象设计原则：
依赖倒置原则（DIP）
• 高层模块(稳定)不应该依赖于低层模块(变化)，二者都应该依赖于抽象(稳定) 。
• 抽象(稳定)不应该依赖于实现细节(变化) ，实现细节应该依赖于抽象(稳定)。
因为，进度通知可能以别的方式展现，比如百分比，而不是进度条。而文件分割功能FileSplitter类不应该依赖界面MainForm类。FileSplitter类中有ProgressBar* m_progressBar。

方法二：ProgressBar* m_progressBar实际是一个通知的作用。因此，可以设计一个通知的基类IProgress。List<IProgress*> m_iprogressList是观察者模式的关键之处。


c++的多继承不建议多有，因为容易带入一些复杂的耦合问题。但是有一种情况推荐使用多继承，一个是主的继承类，其它的是接口类或抽象类。

2 模式定义

定义对象间的一种一对多（变化）的依赖关系，以便当一个对象(Subject)的状态发生改变时，所有依赖于它的对象都得到通知并自动更新。

——《设计模式》GoF

3 结构（Structure）

红色为部分是稳定的，蓝色部分是变化的。

Observer相对于IProgress，其下的Update()相当于DoProgress()。
GOF中建议提出Subject基类，然后让子类继承该基类的三个方法。
Subject中的Attach()相当于addIProgress()
Detach()相当于removeIProgress()
Notify()相当于onProgress()
本例子中，没有抽象出Subject基类，而是把这三个方法直接放在FileSplitter类中实现，即把Subject和ConcreteSubject放在一起。这也是可以的，提不提出Subject基类都是观察者模式。
ConcreteObserver则是MainForm和ConsoleNotifier，即具体的观察者。

4 要点总结

（1）使用面向对象的抽象，Observer模式使得我们可以独立地改变目标与观察者，从而使二者之间的依赖关系达致松耦合。
说明：MainForm随意添加任意的观察者，FileSplitter不受影响。
（2）目标发送通知时，无需指定观察者，通知（可以携带通知信息作为参数）会自动传播。
说明：FileSplitter在onProgress中发布通知，针对整个通知机制进行抽象的通知，观察者MainForm自己决定是否要订阅通知。

（3）观察者自己决定是否需要订阅通知，目标对象对此一无所知。

（4）Observer模式是基于事件的UI框架中非常常用的设计模式，也是MVC模式的一个重要组成部分。

观察者模式和模板方法都是常用的设计模式。可以在代码上有不同的展现形式，关键之处是抽象的通知依赖关系。