3.4 在开发中使用设计模式

现在，我们应该对设计模式的本质以及它们的组织方式有了初步的认识，并且能够理解ROPES过程在整体设计中的作用。通过之前章节对“体系结构”及其五个视图的探讨，我们打下了坚实的基础。初步了解了UML的基本构建模块后，我们现在可以开始深入学习本书介绍的模式，并探讨如何将它们应用到我们的应用开发工作中。接下来，让我们简要讨论一下如何在日常工作中有效地运用这些设计模式。

首先，我们需要了解模式的适用范围。模式一般适用于以下场景：

• 解决具有相似问题的设计问题
• 提高系统的可重用性、可扩展性、可维护性等
• 提高系统的性能、安全性等

3.4.1 模式孵化：找到正确的模式

当我们面临设计问题时，如何找到解决这个特定问题的模式呢？图3.10给出了本书推荐的多步方法。

1. 熟悉模式

在开始设计之前，你必须熟悉有关模式的各种文献。有许多书籍、文章、网站都讨论了模式在各个领域的应用。本书只介绍了一部分，其他的模式可查参考文献。一旦你掌握了更多的模式词条，特别是和你的应用域密切相关的模式词条，面对设计挑战时，就有了更多智力弹药。

2. 学会思考

“学会思考”是指刻画你面临的设计问题的本质。问题的范围是什么？是做体系结构、某个机制，还是详细设计？最切题的服务质量问题是什么？是性能、可复用性、安全性、可移植性，还是内存使用？将这些按紧要程度分类。有时一旦你做了这一步，本身可能暗示某种设计的解决方案。

3. 模式匹配

模式匹配是指将你的设计问题与已知的模式进行比较，寻找相似之处。这是很好玩的一步。大脑皮层是一架奇妙的模式匹配机，它按学会的思考自动运作处理。这是你在洗澡、睡觉、吃饭时随时都可能体验到“我知道了！”的原因。一旦会用“学会思考”的步骤，你的模式匹配机就有足够的信息下意识地连续运作。

4. 奇迹发生

在设计模式的实践中，“奇迹发生”时刻是一个标志性的转折点。此时，经过一系列的模式匹配努力，我们终于捕捉到了一个潜在的解决策略。这个策略可能并不完美，也许未曾明确地形成通用的解决方案，但它与我们期望的特性紧密相连，为未来的发展和迭代提供了一个有希望的起点。

5. 评估解决方案

你需要评估它是否可行。这包括考虑模式的适用性、解决方案的完整性和可靠性等因素。如果这个解决方案很好，转向步骤6，采用它；如果不好，在澄清以后转向步骤3，甚至转向步骤2。

6. 实例化模式

实例化模式是指将模式的抽象概念转化为具体的设计元素。这包括拆开、合并对象，重新派定协作的职责，或引入新的元素补全等。

7. 测试解决方案

在实例化模式后，你需要测试解决方案是否满足需求。这包括用协作元素再现分析场景，证实它们是否满足功能和行为需求。一旦你满意协作做的事，就可度量所希望的服务质量，如有必要，还需保证这些模式能达到你的服务质量目标。性能和资源利用目标更应如此。

3.4.2 模式挖掘：打磨出自己的模式

创建自己的模式是一种非常有用的设计技巧，尤其是当你对某个特定领域的优化问题有了深刻的体验和理解，对解决方案的一般性质有了足够广泛的理解，足以将它们抽象为泛化的解决方案时。我们把这称为模式挖掘。

模式挖掘并不是多么了不起的发明创造，它只是简单地将在某个上下文中的解决方案与另一个上下文中的解决方案进行比较，找出它们的相似之处，并抽象出这些相似之处。

要想做出一个有用的模式，它必须满足以下条件：

• 它必须能够在不同的上下文中重复使用。
• 它必须能够为一个或多个服务质量带来有用的改进。

3.4.3 模式实例化：在设计中运用模式

模式实例化是模式挖掘的逆过程。它将模式应用于某个特定的协作，以发挥模式的效益。

模式通常用于对象协作。协作是对象的集合。协作的范围可以很大或很小，小到底层对象，达到子系统和构件。模式实例化的目的是用模式来组织已经存在的协作方案，或者对其进行改进。

在设计中应用或实例化模式，就是定义元素来满足协作中的角色。对于某些模式，可以创建超类来表示角色，然后再使用子类来实例化模式。对于另一些模式，可以使用应用域中的某些元素来替换模式元素，并添加所需的操作和行为。还可以选择性地创建某些对象，就像它们存在于模式中一样。