代码世界的守护者：设计模式入门

代码世界的守护者：设计模式入门

The Guardians of the Code World: Introduction to Design Patterns

想象你正漫步在一个宁静的小镇上。清晨的阳光洒在鹅卵石铺就的街道上，空气中弥漫着新鲜面包的香气。你注意到镇中心有一座独特的建筑——那是镇上的邮局。这座邮局已经矗立在这里超过一个世纪，见证了无数次技术革新：马车的消失、汽车的出现、电话的普及、互联网的兴起。然而，无论外部世界如何变化，这座邮局始终在为镇上的居民提供着稳定、可靠的服务。

你可以走进邮局，仔细观察它的内部结构。你会发现，尽管邮局的柜台经历过无数次翻修，邮件分拣系统已经从手工操作升级为计算机自动化，但邮局的核心设计理念从未改变：信件被分类、编号、追踪，最终准确无误地送达收件人手中。这种设计是如此精妙，以至于每一代新的邮局工作人员都能快速上手，因为基本的运作模式已经被完美地定义和重复验证过无数次了。

这座邮局的建筑师——或者说这座建筑的设计者——可能从未想过，他创造的不只是一个物理空间，而是一种模式。一种被反复验证、行之有效的解决问题的方式。

Pattern：跨越时空的智慧

在英语中，"Pattern"这个词有着丰富的含义。它可以指花纹、图案，也可以指模式、范式。Christopher Alexander——这位奥地利裔英国建筑师将在后文中扮演重要角色——给这个词赋予了全新的定义：Pattern 是对特定上下文（Context）中反复出现的问题（Problem）的通用解决方案（Solution）的描述。

让我们用更通俗的话来理解这个定义。

想象你是一位木匠，你要制作一把椅子。无论你是18世纪法国凡尔赛宫的宫廷工匠，还是21世纪深圳家具厂的现代匠师，你都会面临一些共同的问题：椅子需要足够稳定、坐着舒适、材料使用要经济、还要具有一定的美观性。经过数百年的摸索，木匠们发现了一些共同的设计原则：四条腿的结构比三条腿更稳定，但如果桌面较重，三条腿可能更简洁；椅背的倾斜角度大约在95度到105度之间最为舒适；腿部最好略微向外倾斜以增加稳定性。这些经过反复验证的设计原则，就是椅子的"模式"。

Pattern 就是这样一种东西：它不是凭空发明的，而是被"发现"的。 正如引力定律在牛顿之前就存在一样，好的设计模式也早已存在于优秀的解决方案中，模式语言只是将它们提炼、命名、归档，使其可以被系统地学习和应用。

从建筑到代码：模式的跨界之旅

Christopher Alexander 与模式语言

要理解设计模式的起源，我们必须回到20世纪70年代。那个时代的建筑界正经历着一场危机：现代主义建筑强调功能性和标准化，却忽视了人的情感需求和生活体验。冰冷的混凝土方盒子、毫无人情味的城市规划，让居住其中的人们感到疏离和不适。

就在这时，一位名叫Christopher Alexander的建筑师站了出来。1926年出生于维也纳的Alexander曾在英国剑桥大学接受教育，后来在加州大学伯克利分校任教。他的研究方向是建筑与城市设计中那些"无名的品质"——那种让人感到舒适、归属、完整的空间体验。

1977年，Alexander发表了里程碑式的论文《模式语言：城镇、建筑、Construction》（*A Pattern Language: Towns, Buildings, Construction*）。在这部著作中，Alexander提出了一个革命性的观点：任何好的建筑和城市设计，都可以通过一套相互关联的模式来描述和创造。 这些模式不是僵硬的规则，而是一系列开放性的原则，每个设计师都可以根据具体情况进行调整和应用。

Alexander在书中定义了253种模式，涵盖了从整个城市到单个房间的各个尺度：

• **城市层面的模式**：比如"独立的生活工作单元"（Independent Living-Working Units）、"放射性街道网络"（Radial Network）等
• **建筑层面的模式**：比如"有入口院落"（Entrance Transition）、"明确路线"（Clear Diagonal Route）等
• **房间层面的模式**：比如"窗户位置"（Windows Facing the Sun）、"家庭聚会空间"（Family Room）等

每一种模式都遵循相同的结构：

1. 标题（Title）：用一个简短而富有意义的名称来标识这个模式 2. 上下文（Context）：描述这个模式适用的场景和环境 3. 问题（Problem）：阐明在这个上下文中需要解决的核心问题 4. forces（张力）：分析影响解决方案的各种因素和它们之间的矛盾 5. 解决方案（Solution）：提供具体的、可操作的设计建议 6. 示意图（Diagram）：用图形化的方式展示模式的结构 7. 关联模式（Related Patterns）：指出这个模式与其他模式的关系

这种标准化的模式描述方式，使得Alexander的模式语言不仅易于理解，更便于传播和应用。一个建筑师学习模式语言，就像一个程序员学习算法和数据结构一样，可以站在前人的肩膀上，快速掌握几百年积累的设计智慧。

GoF：软件世界的模式先驱

Alexander的模式语言在建筑界产生了深远影响，但其真正的革命性影响却出现在一个完全不同的领域——计算机软件。

1994年，四位软件工程师 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 聚在一起，决心做一件前无古人的事情：系统性地整理和记录软件设计中反复出现的解决方案。这四位作者后来被业界尊称为"四人帮"（Gang of Four，简称GoF），他们合著的《设计模式：可复用面向对象软件的基础》（*Design Patterns: Elements of Reusable Object-Oriented Software*）成为了软件工程史上最具影响力的著作之一。

这本书的诞生有其特定的历史背景。20世纪80年代末到90年代初，面向对象编程（Object-Oriented Programming，简称OOP）正在成为软件开发的主流范式。Smalltalk、C++等面向对象语言的兴起，让程序员们第一次拥有了强大的工具来构建复杂系统。然而，OOP虽然提供了类和继承等抽象机制，却并没有告诉程序员们"如何"设计这些类和继承结构。

GoF的贡献在于，他们从大量成功的面向对象系统中，识别出了23种反复出现的设计模式。这些模式涵盖了类与对象协作的各个方面，每一种都针对特定类型的设计问题提供了经过验证的解决方案。

举一个简单的例子。假设你要开发一个图形编辑软件，用户可以绘制圆形、矩形、三角形等基本图形。用户可能需要撤销（Undo）刚刚的操作，或者同时选中多个图形进行批量操作。在没有设计模式指导的情况下，你可能会写出大量重复且难以维护的代码。但如果你运用了组合模式（Composite Pattern）和命令模式（Command Pattern），整个系统的结构会变得清晰得多：

• 组合模式让你可以用统一的方式处理单个图形和图形组
• 命令模式让每个操作都可以被记录、撤销和重做

这正是设计模式的价值：它们不是凭空想象的发明，而是从成功的系统中提炼出来的经验总结。

23张王牌：设计模式的完整图谱

GoF的23种设计模式，按照其用途和实现方式，被清晰地分为三大类别。这种分类不仅便于学习和记忆，更重要的是，它揭示了设计模式之间的内在逻辑关系。

创建型模式：对象的诞生艺术

Creational Patterns（创建型模式）关注的是"如何创建对象"这个问题。在面向对象编程中，对象的创建看似简单，实际上却可能涉及到复杂的逻辑：如果一个类有很多子类，创建对象时需要选择实例化哪一个子类怎么办？如果创建对象的过程需要大量配置参数怎么办？如果系统需要控制创建对象的数量（比如只允许一个实例）怎么办？

创建型模式正是为了解决这些问题而设计的。它们将对象的创建与使用分离，封装了"如何创建"的知识，让代码更加灵活和可维护。

GoF定义了5种创建型模式：

1. 单例模式（Singleton Pattern） 确保一个类只有一个实例，并提供一个全局访问点。这是最简单也最常用的模式之一。比如，一个应用程序只能有一个日志管理器，一个数据库连接池通常也只需要一个实例。单例模式确保了全局唯一性，避免了资源浪费和状态不一致的问题。

```python class Singleton: """单例模式示例""" _instance = None

def __new__(cls): if cls._instance is None: cls._instance = super().__new__(cls) cls._instance._initialized = False return cls._instance

def __init__(self): if not self._initialized: self._initialized = True

初始化代码

pass

测试

singleton1 = Singleton() singleton2 = Singleton() print(singleton1 is singleton2) # True：两个变量指向同一个实例 ```

2. 工厂方法模式（Factory Method Pattern） 定义一个创建对象的接口，但让子类决定实例化哪个类。工厂方法模式将对象的创建延迟到子类，使得系统可以在不修改现有代码的情况下引入新的产品类型。

3. 抽象工厂模式（Abstract Factory Pattern） 提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。当系统需要创建多个产品族中的对象时，抽象工厂是理想的选择。比如，一个跨平台的UI库可能需要在Windows系统下创建Windows风格的文件对话框、按钮和菜单，而在Mac系统下创建Mac风格的相应组件。

4. 建造者模式（Builder Pattern） 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。建造者模式特别适合创建那些具有多个可选组件的对象。比如，一个汽车建造者可以按需装配不同的发动机、轮胎、内饰，最终生产出经济型轿车或豪华SUV。

5. 原型模式（Prototype Pattern） 通过复制现有对象（原型）来创建新对象，而不是直接实例化类。原型模式在需要创建大量相似对象时特别有用，可以显著提升性能。比如，在图形编辑器中，用户可能需要复制一个复杂的图形对象数百次，使用原型模式可以避免重复的配置过程。

结构型模式：构建稳健的架构

Structural Patterns（结构型模式）关注的是"如何组合类和对象以形成更大的结构"。在软件系统中，类和对象不是孤立存在的，它们需要相互协作，形成各种复杂的关系网络。结构型模式正是帮助我们更好地组织这种关系。

6. 适配器模式（Adapter Pattern） 将一个类的接口转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。这就像现实生活中的电源适配器：美国笔记本电脑的插头无法直接插入欧洲的插座，但有了适配器，问题就迎刃而解了。

```python class EuropeanSocket: """欧洲标准的插座""" def voltage(self): return 220

def live(self): return 1

def neutral(self): return -1

class AmericanPlug: """美国标准的插头""" def __init__(self): self.name = "美国插头" self.voltage = 110

class Adapter: """适配器：将美国插头转换为欧洲插座接口""" def __init__(self, plug: AmericanPlug): self.plug = plug

def voltage(self):

将110V转换为220V

return 220 if self.plug.voltage == 110 else self.plug.voltage

def live(self): return self.plug.voltage

def neutral(self): return 0

使用示例

socket = EuropeanSocket() plug = AmericanPlug() adapter = Adapter(plug) print(f"适配后电压: {adapter.voltage()}V") # 输出：适配后电压: 220V ```

7. 桥接模式（Bridge Pattern） 将抽象部分与它的实现部分分离，使它们都可以独立变化。桥接模式避免了类的爆炸式增长。比如，一个跨平台的图形系统可能有多种图形类型（圆形、矩形等）和多种渲染方式（光栅渲染、矢量渲染）。如果用继承来实现，所有组合的可能性会导致类数量急剧膨胀。但使用桥接模式，图形和渲染方式可以独立变化。

8. 组合模式（Composite Pattern） 将对象组合成树形结构以表示"部分-整体"的层次结构。组合模式让用户对单个对象和组合对象的使用具有一致性。在开头的邮局故事中，组合模式就像是邮局系统中的文件夹结构：一个文件夹可以包含多个文件，也可以包含子文件夹。组合模式让我们可以用统一的操作（打开、删除、复制）来处理文件和文件夹。

9. 装饰器模式（Decorator Pattern） 动态地给对象添加一些额外的职责。装饰器模式比继承更加灵活，因为可以在运行时选择性地给对象添加功能。比如，Java的I/O流系统大量使用了装饰器模式。你可以用BufferedInputStream装饰FileInputStream来添加缓冲功能，用DataInputStream装饰来添加数据类型读取功能。

10. 外观模式（Facade Pattern） 为子系统中的一组接口提供一个统一的接口。外观模式定义了一个高层接口，使得子系统更易于使用。就像邮局的接待窗口：无论内部有多少复杂的分拣和投递流程，对外只提供一个简单的寄信接口。

11. 享元模式（Flyweight Pattern） 运用共享技术有效地支持大量细粒度的对象。当系统需要创建大量相似对象时，享元模式可以节省大量内存。比如，一个文字编辑器需要显示数千个字符，每个字符都需要渲染。如果每个字符都创建一个独立的对象，内存消耗将非常惊人。享元模式通过共享字符的内在状态（如字符代码、字体信息），只对每个字符的外在状态（如位置）单独存储，大大节省了资源。

12. 代理模式（Proxy Pattern） 为其他对象提供一种代理以控制对这个对象的访问。代理模式可以在不改变原始对象的情况下，为其添加访问控制、延迟加载、日志记录等功能。就像智能卡芯片的代理：你不需要直接操作芯片内部的复杂电路，只需要通过标准化的接口与之交互。

行为型模式：协作的艺术

Behavioral Patterns（行为型模式）关注的是"对象之间的通信和职责分配"。在复杂的系统中，对象之间需要相互协作，但如何组织这种协作本身就是一门艺术。行为型模式提供了多种经过验证的协作模式。

13. 责任链模式（Chain of Responsibility Pattern） 将请求的发送者和接收者解耦，让多个对象有机会处理请求。当一个请求从链的头部出发，每个对象都可以决定处理这个请求还是将其传递给下一个对象。比如，一个请假申请系统：3天以内的假由主管批准，7天以内的假需要经理批准，更长的假期需要总监批准。使用责任链模式，请假申请会自动沿着链条传递，直到找到能处理它的管理者。

14. 命令模式（Command Pattern） 将请求封装成对象，从而让你可以用不同的请求参数化客户，对请求排队或记录请求日志，以及支持可撤销的操作。命令模式把"发送请求的对象"和"执行请求的对象"分开。比如，遥控器上的每个按钮都是一条命令：开灯、关灯、调高音量。遥控器不需要知道具体如何执行这些命令，它只需要知道每个按钮对应一个命令对象。

```python from abc import ABC, abstractmethod

class Command(ABC): """命令接口""" @abstractmethod def execute(self): pass

@abstractmethod def undo(self): pass

class LightOnCommand(Command): """开灯命令""" def __init__(self, light): self.light = light

def execute(self): self.light.turn_on()

def undo(self): self.light.turn_off()

class LightOffCommand(Command): """关灯命令""" def __init__(self, light): self.light = light

def execute(self): self.light.turn_off()

def undo(self): self.light.turn_on()

class RemoteControl: """遥控器：命令的调用者""" def __init__(self): self.history = []

def execute_command(s