软件构造系列学习笔记（5.3）————可复用性的设计模式

可复用性的设计模式

除了Framework，5-2节所讨论的其他技术都过于“基础”和“细小”，有没有办法做更大规模的复用设计？
本节：几种典型的“面向复用”的设计模式。

目录

• 适配器模式（Adapter）
• 装饰器模式（Decorator ）
• 外观模式（Facade）
• 策略模式（Strategy）
• 模板方法模式（Template method）
• 迭代器模式（ Iterator）

除了类本身，设计模式更强调多个类/对象之间的关系和交互过程—比接口/类复用的粒度更大。

Structural patterns 结构型模式

结构型模式包含了前三种设计模式，包括适配器模式，装饰器模式和外观模式。下面一一进行介绍。

适配器模式（Adapter）

目的：将某个类/接口转换为client期望的其他形式。
适配器让类可以协同工作，否则就会因为不兼容的接口而无法工作。通过增加一个接口，将已存在的子类封装起来，client面向接口编程，从而隐藏了具体子类。

对象：将旧组件重用到新系统（也称为“包装器”）。
来看下面一个例子：

如果不使用适配器模式，会出现如下问题：

采用适配器模式后就能解决这一问题：

通过这个例子我们就可以了解到适配器模式的作用了。

装饰器模式（Decorator）

装饰器模式是为了解决以下问题出现的一个设计模式：为对象增加不同侧面的特性。
在这种设计模式下，我们对每一个特性构造子类，通过委派机制增加到对象上。

考虑以下问题：
假设你需要Stack数据结构的各种扩展。

• UndoStack：一个允许你撤销先前的push或pop操作的栈
• SecureStack：一个需要密码的栈
• SynchronizedStack：一个串行化并发访问的栈

我们可以采用继承的方式来解决。
之后我们又需要任意可组合的扩展：

• SecureUndoStack：需要密码的堆栈，并且还可以撤消以前的操作
• SynchronizedUndoStack：一个堆栈，用于序列化并发访问，还可以让您撤销先前的操作
• SecureSynchronizedStack：…
• SecureSynchronizedUndoStack：…

我们又怎么处理呢？继承层次结构？多继承？但是会显得很麻烦，这时候装饰器模式就可以很好地解决这一问题。

构建一个普通的堆栈：

Stack s = new ArrayStack(); 

构建撤消堆栈：

UndoStack s = new UndoStack(new ArrayStack()); 

构建安全的同步撤消堆栈：

SecureStack s = new SecureStack( 
                    new SynchronizedStack( 
                        new UndoStack(s))

装饰器 vs. 继承

• 装饰器在运行时组成特征；继承在编译时组成特征。
• 装饰器由多个协作对象组成；继承产生一个明确类型的对象。
• 可以混合和匹配多个装饰；多重继承在概念上是困难的。

java.util.Collections中也有一些装饰器模式：
将mutable list 变为 immutable list:

static List<T>  unmodifiableList(List<T> lst); 
static Set<T>   unmodifiableSet( Set<T> set); 
static Map<K,V> unmodifiableMap( Map<K,V> map); 

Similar for synchronization:

static List<T>  synchronizedList(List<T> lst); 
static Set<T>   synchronizedSet( Set<T> set);
static Map<K,V> synchronizedMap( Map<K,V> map);

外观模式（Facade）

外观模式是为了解决客户端需要通过一个简化的接口来访问复杂系统内的功能这一问题提出的。

意图是提供一个统一的接口来取代一系列小接口调用，相当于对复杂系统做了一个封装，简化客户端使用。便于客户端学习，解耦 。

下面举例来说明这一设计模式：
假设我们有一个具有一组接口的应用程序来使用MySql / Oracle数据库，并生成不同类型的报告，如HTML报告，PDF报告等。
因此，我们将有不同的接口集合来处理不同类型的数据库。现在客户端应用程序可以使用这些接口来获取所需的数据库连接并生成报告。但是，当复杂性增加或界面行为名称混淆时，客户端应用程序将难以管理它。
因此，我们可以在这里应用Facade模式，并在现有界面的顶部提供包装界面以帮助客户端应用程序。

Two Helper Classes for MySQL and Oracle：

A façade class:

客户端代码：

可以看到采用了Facade设计模式的客户端代码简洁了许多，更方便客户使用。

行为类模式

行为类模式包含了后三种设计模式，包括策略模式，模板模式和观察模式。

策略模式（ Strategy）

问题：针对特定任务存在不同的算法，但客户端可以根据动态上下文在运行时切换算法。
示例：对客户列表进行排序（冒泡排序，合并排序，快速排序）
解决方案：为算法创建一个接口，并为算法的每个变体创建一个实现类。
优点：

• 易于扩展新算法实现
• 从客户端上下文中分离算法

另外一个例子：

模板模式（Template Method）

问题：几个客户共享相同的算法，但具体细节不同，即算法由可定制的部分和不变的部分组成。 常见的步骤不应该在子类中重复，但需要重新使用。简而言之就是做事情的步骤一样，但具体方法不同。
示例：

• 执行测试用例测试组件
• 打开，阅读和编写不同类型的文档

解决方法：共性的步骤在抽象类内公共实现，差异化的步骤在各个子类中实现。

一般使用继承和重写实现模板模式。 模板模式在框架中广泛使用。用UML图描述见下图。

接着我们看下面一个具体例子：

具体代码如下：

客户端就可以这样使用：

OrderProcessTemplate netOrder = new NetOrder(); 
netOrder.processOrder();

OrderProcessTemplate storeOrder = new StoreOrder(); 
storeOrder.processOrder();

迭代器模式（Iterator）

问题：客户需要统一的策略来访问容器中的所有元素，与容器类型无关
解决方案：迭代器策略模式
结果：

• 隐藏底层容器的内部实现
• 支持多个遍历策略，界面统一
• 易于更改容器类型
• 便于部分程序之间的通信

这种模式让自己的集合类实现Iterable接口，并实现自己的独特Iterator迭代器(hasNext, next, remove），允许客户端利用这 个迭代器进行显式或隐式的迭代遍历。UML图如下：

Iterable接口：实现该接口的集合对象是可迭代遍历的

public interface Iterable<T> { 
    ... 
    Iterator<T> iterator(); 
} 

Iterator接口：迭代器

public interface Iterator<E> { 
    boolean hasNext(); 
    E next(); 
    void remove(); 
}

具体例子见下图：