设计模式之“组件协作“模式：Template Method、Strategy、Observer

---

  现代软件专业分工之后的第一个结果是“框架与应用程序的划分”，“组件协作”模式通过晚期绑定，来实现框架与应用程序之间的松耦合，是二者之间协作时常用的模式。(早期和晚期是对应于开发过程而言的，对于一个基类而言，其派生类与基类就为晚期绑定关系，对于由应用实现库中所调用函数的设计方式，则库和流程函数(一般是main函数，即程序/流程入口)为早期绑定关系)。

本文的三种设计模式解决的是框架和应用之间的协作问题。

---

---

1. Template Method 模板方法模式

---

1.1 Template Method 动机

在软件构建过程中，对于某一项任务，它常常有稳定的整体操作结构，但各个子步骤却有很多改变的需求，或者由于固有的原因（比如框架与应用之间的关系）而无法和任务的整体结构同时实现。

那么如何在确定稳定操作结构的前提下，来灵活应对各个子步骤的变化或者晚期实现需求？

早期绑定示例

晚期绑定示例

---

1.2 模式定义

定义一个操作中的算法的骨架 (稳定)，而将一些步骤延迟(变化)到子类中。Template Method使得子类可以不改变(复用)一个算法的结构即可重定义(override 重写)该算法的某些特定步骤。

---

1.3 示例代码

早绑定示例代码：

template1_app.cpp

template1_lib.cpp

晚绑定示例代码：

template2_app.cpp

template2_lib.cpp

---

1.4 要点总结

• Template Method模式是一种非常基础性的设计模式，在面向对象系统中有着大量的应用。它用最简洁的机制（虚函数的多态性，运行时多态可见：C++的动态绑定和静态绑定）为很多应用程序框架提供了灵活的扩展点，是代码复用方面的基本实现结构。即使用虚函数多态来实现代码复用和扩展；
• 除了可以灵活应对子步骤的变化外，特征为“不要调用我，让我来调用你”的反向控制结构是Template Method的典型应用。
• 在具体实现方面，被Template Method调用的虚方法可以具有实现，也可以没有任何实现（抽象方法、纯虚方法），但一般推荐将它们设置为protected方法(因为一般是内部在接口中进行内部调用，不宜暴露过多函数接口，这样会导致封装性降低)。

---

---

2. Strategy 策略模式

---

2.1 Strategy 策略模式动机

在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一个性能负担。

那么如何在运行时根据需要透明地更改对象的算法？将算法与对象本身解耦，从而避免上述问题？

---

2.2 模式定义

定义一系列算法，把它们一个个封装起来(封装为基类或是函数指针)，并且使它们可互相替换（变化）。该模式使得算法可独立于使用它的客户程序(稳定)而变化（扩展，子类化）。抽象UML图如下：

和 STL 中谓词(predicate)的实现相同，同时与 STL 的 functor 有相通之处；
对于图中的DIP原则，可见：2. 面向对象设计原则；对于图中函数指针的方案，示例见：c++中的函数指针转函数参数。

---

2.3 示例代码

在进行税费结算的系统中，倘若现下只需实现与几个国家的税费结算业务，但是很有可能今后随着发展会增添新的国家的税费计算功能。

简单思路就是对现下所有的税率进行枚举，并在业务类中指定相关的枚举类型，在计算时进行if-else判断对税费进行计算，现在这个方法，若是在新加入税率或是原有税率进行更改的时候，就需要改动源码并重新编译业务类的代码了，这是不可取的。

若是使用 strategy 策略，可以对新的税率或更改税率进行派生新税率类型或是只更改原有的税率类型，不再更改业务类的代码，使得业务类的可重用性大大增强，使得类型在运行时可方便地根据需要在各个算法之间进行切换。

strategy1.cpp（枚举，使用if-else进行税费计算）

strategy2.cpp（使用strategy策略，创建新派生类参与税费计算）

---

2.4 要点总结

• Strategy及其子类为组件提供了一系列可重用的算法，从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换。
• Strategy模式提供了用条件判断语句以外的另一种选择，消除条件判断语句，就是在解耦合(strategy策略的使用场景之一就是在算法接口中出现了大量的if-else判断结构)。含有许多条件判断语句的代码通常都需要Strategy模式。
• 如果Strategy对象没有实例变量，那么各个上下文可以共享同一个Strategy对象(单例模式)，从而节省对象开销。

---

---

3. Observer 观察者模式

---

3.1 Observer 观察者模式动机

在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系” ——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。

那么如何使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系，从而实现软件体系结构的松耦合呢？

---

3.2 模式定义

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

3.3 示例代码

对于早期软盘时代，存储容量较小，所以会将较大的文件分割为多个小文件，对其进行分别存储。以下示例代码是想要在进行文件分割的过程中对分割进度用进度条进行显示。博主本人的本科毕设就添加过进度条功能，不过没有用到观察模式，而是所见即所得的简单观察者和被观察者的编译绑定，没有进行抽象。

紧耦合，FileSplitter 和 progressBar 对象绑定：

MainForm1.cpp

FileSplitter1.cpp

松耦合，FileSplitter 和 progressBar 对象中间通过 IProgress 抽象类进行关联：

可同时支持多个观察者的挂载观察(一对多关系的体现)，且 FileSplitter 进度更新不再依赖于具体的观察者类型，实现了新的定制观察者加入时，不用更改 FileSplitter.cpp 并重新编译；

MainForm2.cpp

FileSplitter2.cpp

---

3.4 要点总结

• 使用面向对象的抽象，Observer模式使得我们可以独立地改变目标与观察者，从而使二者之间的依赖关系达致松耦合。
• 目标发送通知时，无需指定观察者，通知（可以携带通知信息作为参数）会自动传播。
• 观察者自己决定是否需要订阅通知，目标对象对此一无所知。
• Observer模式是基于事件的UI框架中非常常用的设计模式，也是MVC模式的一个重要组成部分。