第1章：设计模式初探 / Chapter 1: First Steps into Design Patterns

拿起一块红色的积木，再拿起一块蓝色的，把它们叠在一起——这是你建造城堡的第一步。但如果你每次建城堡都要重新发明怎么叠积木，那可能要花一辈子才能建成一座宏伟的城堡。幸好，聪明的孩子们早就发现了一些“积木搭建秘诀”：比如“先用大积木打地基”、“在角落放三角积木做屋顶”。这些秘诀被一代代传下来，后来，连建造摩天大楼的工程师们也使用了类似的思路。在编程的世界里，这些“秘诀”就叫做设计模式（Design Patterns）——一套被验证过的、解决常见问题的“代码搭建指南”（code building guides）。它们不是具体的代码，而是经过千锤百炼的“蓝图”（blueprints），告诉你当遇到特定问题时，最优雅、最灵活的解决思路是什么。就像你学会了“三角屋顶”秘诀后，可以把它用在城堡、小屋甚至飞船的建造上，设计模式让你不必每次从头开始，而是站在“巨人的肩膀”上，快速构建出健壮、易维护的程序。

那么，这些“秘诀”从何而来？它们如何分类？又该如何用“魔法地图”（UML图）来读懂它们？本章将带你踏上设计模式的首次探险。我们将从最经典的“搭积木”比喻出发，揭开设计模式的神秘面纱，探索它们的家族谱系（创建型、结构型、行为型），并亲手绘制第一张“魔法地图”。最后，我们会进入一个童话故事，结识策略模式（Strategy Pattern）这位“变形大师”，看看它如何让程序像变色龙一样灵活变化。准备好了吗？让我们推开魔法屋的大门，开始这场智慧与乐趣并存的旅程！

设计模式（Design Patterns）的核心思想是“复用成功的经验”。在软件工程中，我们经常遇到相似的问题：比如需要创建一个对象，但不确定具体类型；或者需要让两个不兼容的系统能够对话；又或者希望一个对象的状态改变时，其他对象能自动收到通知。如果每次遇到这些问题都从头发明解决方案，不仅效率低下，而且容易引入错误。设计模式就像是“问题-解决方案”的配对卡片：当你看到某种问题场景（Problem），就能想到对应的模式卡片（Solution），直接应用那些被广泛验证的最佳实践。这种复用不是复制粘贴代码，而是复用“设计思想”——一种更高层次的抽象。

这种思想并非软件行业的独创。事实上，它最早源于建筑学。1977年，加州大学伯克利分校的建筑学教授克里斯托弗·亚历山大（Christopher Alexander）出版了《建筑模式语言》（A Pattern Language: Towns, Buildings, Construction）一书。他在书中记录了253个建筑模式，从“城市边界”到“窗户位置”，每个模式都描述了问题、解决方案和原理。例如，“阳光下的露台”模式建议：露台应朝南，有墙壁遮挡北风，并种植落叶植物以调节季节光照。这些模式不是设计图纸，而是生成设计的“规则语言”，让非专业建筑师也能建造舒适宜居的房屋。亚历山大在书中写道：“每个模式都是一种在此情境下解决问题的关系……它描述了一个在环境中重复出现的问题，并提出了该问题的核心解决方案。” 这种“模式”概念很快被软件先驱们注意到。

1987年，软件工程师沃德·坎宁安（Ward Cunningham）在奥斯拉格（OOPSLA）会议上首次公开提出：可以将亚历山大模式语言的思想应用于软件设计。他展示了如何用模式描述Smalltalk程序中的常见结构。这一观点像一颗火种，点燃了面向对象社区的灵感。随后，四位才华横溢的软件工程师——埃里希·伽玛（Erich Gamma）、理查德·赫尔姆（Richard Helm）、拉尔夫·约翰逊（Ralph Johnson）和约翰·弗利迪斯（John Vlissides）——开始系统性地收集、整理和验证软件设计中的模式。他们被合称为“GoF”（Gang of Four，四人组）。经过数年协作，他们于1994年出版了划时代的著作：《设计模式：可复用面向对象软件的基础》（Design Patterns: Elements of Reusable Object-Oriented Software）。这本书首次提出了23个经典设计模式，并给出了标准的分类和描述模板，成为软件开发的“圣经”。据统计，该书已被引用超过5万次，全球销量逾50万册，深刻影响了Java、C#、C++等面向对象语言的发展。GoF在序言中写道：“这本书不是一本介绍性读物，而是一本参考手册……我们关注的是在特定情境下反复出现的设计问题，以及应对这些问题的优雅解决方案。” 从此，“设计模式”正式成为软件工程师的通用词汇。

GoF的23个模式并非随意挑选，而是基于严格的筛选标准。他们只收录那些“在多种应用中被反复验证”、“能解决特定设计问题”、“不依赖于具体实现细节”的模式。每个模式都遵循固定的描述结构：意图（Intent）、动机（Motivation）、适用性（Applicability）、结构（Structure）、参与者（Participants）、协作（Collaborations）、效果（Consequences）、实现（Implementation）、示例（Sample Code）、已知应用（Known Uses）和相关模式（Related Patterns）。这种严谨性确保了模式的可复用性和教学价值。对于儿童学习者而言，我们不需要一开始就掌握所有细节，但要知道：这些模式是“经过时间考验的智慧结晶”，不是某个人灵光一现的发明。当你使用单例模式（Singleton）确保只有一个游戏管理员时，你其实在使用数十年来无数开发者验证过的方案；当你用观察者模式（Observer）让角色血条自动更新时，你站在GoF和其他千千万万程序员的肩膀上。这种集体智慧（collective wisdom）正是设计模式魔力的源泉。

GoF将23个模式分为三大类，宛如将魔法分为不同的系别：创建型（Creational）、结构型（Structural）和行为型（Behavioral）。这种分类基于模式关注的设计问题不同：创建型模式处理“对象的诞生”，结构型模式处理“对象的组合”，行为型模式处理“对象的协作”。理解这个分类，就像拿到一张魔法地图，能帮你快速定位需要的模式。下面，我们用儿童熟悉的比喻来探索每个家族。

创建型模式（Creational Patterns）关注对象的创建过程。它们像“玩具制造专家”，帮你决定“如何得到一个新对象”，而不仅仅是直接new出来。为什么这很重要？因为如果代码中到处写`new Dog()`、`new Cat()`，将来想换成`new Robot()`就会处处修改，非常麻烦。创建型模式将创建逻辑封装起来，让系统对“创建什么”和“怎么创建”更灵活。这个家族有五个成员：

• **单例模式（Singleton）**：确保一个类只有一个实例，并提供一个全局访问点。就像学校只有一个校长室，无论谁要找校长，都去那个房间。在游戏中，最终BOSS只能有一个，否则游戏就乱了。单例模式保证`GameManager`或`AudioController`全局唯一。
• **工厂方法模式（Factory Method）**：定义一个创建对象的接口，但让子类决定实例化哪个类。就像自助餐厅的菜单：厨师（父类）说“我能做吃的”，但具体做汉堡还是沙拉，由点餐的孩子（子类）决定。这样，新增食物类型时，不需要修改厨师代码。
• **抽象工厂模式（Abstract Factory）**：提供一个接口，用于创建相关或依赖对象的家族，而不需要指定具体类。就像“魔法套装商店”：你想买一套巫师装备（帽子、袍子、魔杖），商店直接给你匹配好的套装，而不是让你分别挑选可能不协调的单件。在图形界面库中，抽象工厂可以创建一套风格一致的按钮、文本框、窗口。
• **建造者模式（Builder）**：将一个复杂对象的构建与其表示分离，使同样的构建过程可以创建不同的表示。就像做汉堡：套餐（汉堡+薯条+饮料）的构建步骤是固定的（先做饼、再加料、后包装），但你可以选择牛肉饼或鸡肉饼，得到不同口味的汉堡。建造者模式分离了“建造流程”和“零件选择”。
• **原型模式（Prototype）**：用原型实例指定创建对象的种类，并通过拷贝这个原型来创建新对象。就像你有一辆最喜欢的玩具车，想得到一模一样的，就按下“克隆按钮”复制一辆，而不是重新画图纸制造。在需要频繁创建相似对象时（如游戏中的子弹），原型模式比new更快。

结构型模式（Structural Patterns）关注类和对象的组合方式。它们像“积木组合大师”，帮你把小さな积木块（类或对象）搭成更大的结构，同时保持结构的灵活和高效。这个家族有七个成员：

• **适配器模式（Adapter）**：将一个类的接口转换成客户希望的另一个接口。就像出国旅行时带的电源转换器：你的中国插头（Adaptee）需要转换成欧洲插座（Target）的形状，才能给手机充电。适配器模式让不兼容的接口能协同工作。
• **桥接模式（Bridge）**：将抽象部分与其实现部分分离，使它们可以独立变化。就像遥控器（抽象）和电视机品牌（实现）：遥控器的按键逻辑（开/关/音量）可以独立于具体电视品牌（索尼、三星）来设计，这样同一个遥控器能适配不同电视。
• **组合模式（Composite）**：将对象组合成树形结构以表示“部分-整体”的层次结构。就像文件夹和文件：你可以把文件夹放进文件夹，形成树，而对用户来说，操作文件夹和操作文件是一样的（都能打开、删除）。组合模式让客户端统一处理单个对象和组合对象。
• **装饰器模式（Decorator）**：动态地给对象添加额外职责，比生成子类更灵活。就像给蛋糕装饰：先有蛋糕胚（组件），然后抹奶油（装饰），再加水果（装饰），每层装饰都包裹前一层，但蛋糕胚还是那个蛋糕胚。Java I/O流就是经典例子：`FileInputStream`被`BufferedInputStream`装饰，获得缓冲能力。
• **外观模式（Facade）**：为子系统中的一组接口提供一个统一的入口，简化调用。就像餐厅服务员：你不需要知道厨房里厨师、洗菜工、配菜员如何协作，只要告诉服务员“我要一份牛排”，服务员会协调所有后端工作。外观模式隐藏了复杂系统的内部细节。
• **享元模式（Flyweight）**：运用共享技术有效地支持大量细粒度对象。就像游戏中的子弹：成千上万颗子弹可能看起来不同（颜色、轨迹），但它们共享相同的“子弹”结构和行为，只有位置、速度等少量状态

2.3 享元模式（Flyweight Pattern）：共享的魔法贴纸

想象一下，你有一本贴满贴纸的相册。有些贴纸是独一无二的，比如你最喜欢的恐龙贴纸；但还有很多贴纸是重复的——比如上百颗金色的星星、几十朵相同的小花。如果每颗星星都单独画一遍，既浪费时间又占地方。聪明的做法是：只画一颗星星的“模板”（master copy），需要时就用这张模板“复印”出星星，再给每颗星星分配一个“位置信息”（比如贴在第几页、坐标是多少）。这样，相册里虽然有一百颗星星，但实际存储的只有一颗星星的图案加上一百组位置数据。享元模式（Flyweight Pattern） 正是这种“共享模板，分离状态”的智慧。它通过共享大量细粒度对象，显著减少内存使用，特别适合处理“大量相似对象”的场景——比如游戏中的子弹、粒子效果、森林里的树木，或者文档中的字符。

享元模式的核心在于区分内部状态（Intrinsic State） 和外部状态（Extrinsic State）。内部状态存储在享元对象内部，不会随环境改变而改变，因此可以被共享。例如，一颗子弹的“形状”、“颜色”、“伤害值”是内部状态，所有相同类型的子弹共享这些数据。外部状态则不能共享，需要由客户端（调用方）保存并在使用时传递给享元。例如，每颗子弹的“位置”、“速度”、“方向”是外部状态，每颗子弹都不同。享元模式就像一个“共享贴纸工厂”：工厂里存着各种贴纸模板（内部状态），当你需要贴纸时，工厂给你一个模板引用，并让你自己记录“贴在哪里”（外部状态）。这样，成千上万的贴纸只需要少量模板就能表示。

让我们通过一个具体的游戏开发例子来理解。假设你正在制作一个太空射击游戏，屏幕上同时存在数千颗子弹。如果每颗子弹都是一个独立的对象，包含位置、速度、加速度、形状、纹理、伤害值等所有数据，那么内存会迅速被耗尽。使用享元模式，我们可以这样设计：

1. 定义享元接口（Flyweight）：声明一个公共接口，通过它接收外部状态并执行操作。例如，`Bullet`接口有一个`render(x, y, rotation)`方法，用于在指定位置和旋转角度渲染子弹。 2. 实现具体享元（ConcreteFlyweight）：实现享元接口，存储内部状态。例如，`LaserBullet`类存储激光子弹的纹理、颜色、伤害值等。这些数据对所有激光子弹都是相同的，因此`LaserBullet`对象只需要一个实例，可以被所有激光子弹共享。 3. 创建享元工厂（FlyweightFactory）：负责创建和管理享元对象。工厂内部有一个 Map（字典），键是享元的标识（如子弹类型“laser”），值是对应的享元实例。当客户端请求一颗“激光子弹”时，工厂检查 Map 中是否已有`LaserBullet`实例，如果有则返回它；如果没有，则新建一个并存入 Map。这样，无论创建多少颗激光子弹，工厂只返回同一个`LaserBullet`实例。 4. 客户端（Client）：保存外部状态，并在调用享元时传入。例如，每颗子弹对象（客户端）只保存自己的`x, y, speed, angle`等外部状态，当需要渲染时，它从工厂获取共享的`LaserBullet`实例，然后调用`bullet.render(x, y, angle)`。

下面是简化的 Python 代码示例，展示了享元模式的核心结构：

```python

享元接口

class Bullet: def render(self, x, y, rotation): pass

具体享元：存储内部状态

class LaserBullet(Bullet): def __init__(self): self.texture = "laser.png" # 内部状态：纹理 self.color = (0, 255, 0) # 内部状态：颜色 self.damage = 10 # 内部状态：伤害值

def render(self, x, y, rotation): print(f"渲染激光子弹于({x},{y})，旋转{rotation}度，纹理{self.texture}")

享元工厂

class BulletFactory: _bullets = {} # 享元池

@classmethod def get_bullet(cls, bullet_type): if bullet_type not in cls._bullets: if bullet_type == "laser": cls._bullets[bullet_type] = LaserBullet() elif bullet_type == "missile": cls._bullets[bullet_type] = MissileBullet()

... 其他类型

return cls._bullets[bullet_type]

客户端：子弹实例（仅保存外部状态）

class BulletInstance: def __init__(self, bullet_type, x, y, speed, angle): self.flyweight = BulletFactory.get_bullet(bullet_type) # 获取共享享元 self.x = x # 外部状态 self.y = y self.speed = speed self.angle = angle

def update(self): self.x += self.speed * cos(radians(self.angle)) self.y += self.speed * sin(radians(self.angle))

def draw(self): self.flyweight.render(self.x, self.y, self.angle)

使用示例

bullets = [] for i in range(1000): # 创建1000颗激光子弹 bullets.append(BulletInstance("laser", i*10, 100, 5, 0))

所有子弹共享同一个LaserBullet实例！

print(f"享元池中实际对象数: {len(BulletFactory._bullets)}") # 输出: 1 ```

在这个例子中，1000颗子弹只占用一个`LaserBullet`对象的内存（内部状态），加上1000组外部状态（位置、速度等）。如果没有享元模式，可能需要1000个完整对象，内存占用大得多。享元模式的关键在于识别并分离内部状态与外部状态。不是所有对象都适合共享：如果对象的状态几乎全部是外部的，或者共享带来的节省微乎其微，那么享元模式可能不值得。通常，它适用于满足以下条件的场景：

• 应用程序创建大量相似对象（如游戏粒子、文档字符）。
• 对象的大多数状态可以外部化，从而在多个对象间共享。
• 对象本身不可变（或很少改变），因为共享意味着一个享元实例被多个客户端使用，如果内部状态被某个客户端修改，会影响到所有客户端。

在图形用户界面（GUI）工具包中，享元模式被广泛应用。例如，在文本编辑器中，每个字符通常是一个对象。如果文档有10万个字符，每个字符都存储字体、大小、颜色等信息，内存会很大。但实际上，同一段落内的字符往往共享相同的字体和大小。享元模式可以让所有'A'字符共享一个“字符享元”，其中存储字体、字形等内部状态，而每个具体'A'的位置、颜色（如果段落内颜色一致则也可共享）作为外部状态。这样，10万个字符可能只需要几十个享元对象。

另一个经典例子是Java的`String`字符串常量池。Java中字符串字面量（如`"hello"`）是享元的：JVM在字符串常量池中只存储一份`"hello"`的字符数组，所有引用`"hello"`的变量都指向同一块内存。这就是为什么`String s1 = "hello"; String s2