模式入门：从代码匠到架构师的蜕变

第 1 章：模式入门：从代码匠到架构师的蜕变

代码匠的困惑

清晨九点，阳光透过落地窗洒进办公室，张明（化名）已经坐在工位前三个小时了。他盯着屏幕上一段不到两百行的代码，眉头紧锁。这段代码他已经改了三版，可产品经理昨天的一句话仍然萦绕在耳边：“这个功能加上去应该很快吧？怎么又要一周？”

张明是一名有五年工作经验的后端工程师，写过的代码不下几十万行。他熟悉各种框架的用法，了解数据库的优化技巧，能在半小时内搭建起一个可用的RESTful API。可是最近他越来越感到一种说不清的无力感——代码越写越多，系统越来越复杂，但每次改需求都像在走钢丝，一个不小心就会引发意想不到的bug。

这种困惑并非张明独有。在软件行业摸爬滚打几年后，很多程序员都会遇到类似的瓶颈：技术上已经“够用”，却总觉得缺少点什么。就像一个熟练的木匠，知道如何使用各种工具，却不懂得如何设计一件家具的结构。

让我们来听听张明的内心独白：“我写的代码能跑，功能也都实现了，但每次看到几个月前自己写的代码，就有种想重写的冲动。这真的是因为我经验不够吗？还是说我缺少某种……我不知道该怎么形容，某种更深层次的东西？”

张明缺少的，正是软件设计中被称为“模式”的智慧。

什么是设计模式

设计模式，这个词听起来有些学术，但它的本质却非常朴素。简单来说，设计模式是针对软件开发中常见问题的最佳解决方案。它不是某一行具体的代码，而是一种经过无数实践验证的思路和方法。

想象一下建筑行业。当你要建造一座房子时，你会直接凭感觉决定梁和柱的位置吗？当然不会。几百年来，建筑师们总结出了各种结构模式：承重墙该放在哪里、横梁该多粗、什么样的屋顶结构最稳固。这些经验被记录下来，成为后人可以学习和借鉴的“建筑模式”。一个学徒不需要从零开始摸索，只需要在前辈的经验基础上进行创新。

软件设计模式的意义与此类似。软件行业经过几十年的发展，前人们已经遇到了无数次类似的问题，并总结出了相应的解决方案。这些方案被整理、归纳、验证，最终形成了我们今天所说的“设计模式”。

模式的三个层次

设计模式并非铁板一块，根据其作用范围和粒度，可以分为三个层次：

1. 代码级模式（Coding Patterns）

这是最细粒度的模式，作用在函数或代码块层面。比如如何正确地处理空值、如何写好一个循环、如何避免嵌套过深的条件判断。这些模式关注的是代码的正确性和可读性，是每个程序员的基本功。

2. 设计模式（Design Patterns）

这是我们本书重点讨论的层次，指的是针对面向对象设计中常见问题的通用解决方案。GoF（Gang of Four，四人帮）在1994年出版的《设计模式：可复用面向对象软件的基础》一书中，总结出了23种经典设计模式。这些模式关注的是类与类之间的关系、如何组织代码结构，以及如何让系统更容易扩展和维护。

3. 架构模式（Architectural Patterns）

这是最高层次的概念，关注的是整个系统的结构和大局。比如常见的MVC架构、微服务架构、分层架构等。架构模式决定了系统的主要组件如何划分、它们之间如何通信、以及系统整体的扩展策略。

本书主要聚焦于第二个层次——设计模式，但也会涉及一些架构层面的内容，因为两者之间的界限并非绝对。

模式的构成要素

一个完整的设计模式通常包含以下几个要素：

模式名称：简短而有意义的名称，便于交流和记忆。比如“单例模式”、“工厂模式”等。

问题描述：在什么场景下会遇到这个问题。比如当你需要确保一个类只有一个实例，并提供一个全局访问点时。

解决方案：如何解决这个问题，包括类的结构、类之间的关系、以及各自的责任分工。

效果权衡：使用这个模式会带来什么好处，可能有什么代价。比如提高了系统的可扩展性，但可能增加了一些复杂性。

理解了这些，我们再来看看设计模式是如何诞生的。

设计模式的诞生：从建筑到软件

设计模式这个概念最早并非来自软件行业，而是来自建筑学。

1987年，Christopher Alexander（克里斯托弗·亚历山大）和他的同事写了一本名为《建筑模式语言》的书。Alexander是一位建筑师，他通过对大量建筑案例的研究，总结出了253种建筑模式，比如“街道之眼”（Street Windows）、“阳台边缘”（Balcony Edge）、“家庭聚集”（Family Gathering）等。每种模式都描述了一个反复出现的建筑问题及其解决方案。

在这本书的序言中，Alexander说了一句后来被软件行业反复引用的话：

> “每一个模式描述了一个在我们环境中反复出现的问题，然后描述了该问题的解决方案的核心，使你能无数次地使用这个解决方案，而不必做同样的工作。”

这句话几乎完美地概括了设计模式的本质。软件行业的先驱们敏锐地意识到，建筑学中“模式”的思想完全可以应用到软件开发中。

1994年，四位计算机科学家——Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides（他们后来被称为“GoF”或“四人帮”），出版了里程碑式的著作《设计模式》。这本书系统地整理了23种面向对象设计中的经典模式，被视为软件设计模式的奠基之作。

这23种模式被分为三大类：

创建型模式（Creational Patterns）：关注对象的创建过程，解决“对象如何被创建”的问题。单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式都属于这一类。

结构型模式（Structural Patterns）：关注如何组合类和对象以形成更大的结构，解决“对象和类如何组织”的问题。适配器模式、装饰器模式、代理模式、桥接模式、组合模式、外观模式、享元模式都是结构型模式的代表。

行为型模式（Behavioral Patterns）：关注对象之间的通信和职责分配，解决“对象之间如何交互”的问题。策略模式、观察者模式、命令模式、模板方法模式、迭代器模式、责任链模式、状态模式、备忘录模式、解释器模式、中介者模式、访问者模式属于这一类。

这三类模式涵盖了面向对象设计中大部分的经典问题场景。掌握了这些模式，就相当于站在了巨人的肩膀上，可以借力前人的智慧来解决自己面临的问题。

为什么需要设计模式

回到我们开头提到的张明。学习了设计模式之后，他开始用一种全新的眼光审视自己的代码。

有一天，产品经理提出了一个新需求：“我们的系统需要支持多种支付方式，除了现有的微信支付，还要加上支付宝、银行卡、甚至以后可能还要支持新的支付渠道。”

按照以前的做法，张明会这样写代码：

```python def process_payment(payment_type, amount): if payment_type == "wechat":

处理微信支付

connect_to_wechat_api() validate_payment(amount) execute_payment() elif payment_type == "alipay":

处理支付宝支付

connect_to_alipay_api() validate_payment(amount) execute_payment() elif payment_type == "bankcard":

处理银行卡支付

connect_to_bank_api() validate_payment(amount) execute_payment()

未来每加一个支付方式，就要在这里加一个分支

```

这段代码看起来没什么问题，但随着支付方式的增加，这段代码会变得越来越长、越来越难以维护。如果某一天微信支付的API变了，你可能需要在代码中的好几处地方做修改。这就是典型的“代码坏味道”——具体来说，是一种被称为“Switch语句”或“重复的分支逻辑”的反模式。

学习了设计模式之后，张明重构了这段代码，使用了策略模式和工厂模式的组合：

```python from abc import ABC, abstractmethod

支付策略接口

class PaymentStrategy(ABC): @abstractmethod def pay(self, amount: float) -> bool: pass

具体的支付策略实现

class WechatPay(PaymentStrategy): def pay(self, amount: float) -> bool: print(f"连接微信支付API...") print(f"验证支付金额: {amount}") print(f"执行微信支付") return True

class Alipay(PaymentStrategy): def pay(self, amount: float) -> bool: print(f"连接支付宝API...") print(f"验证支付金额: {amount}") print(f"执行支付宝支付") return True

class BankCardPay(PaymentStrategy): def pay(self, amount: float) -> bool: print(f"连接银行API...") print(f"验证支付金额: {amount}") print(f"执行银行卡支付") return True

策略工厂

class PaymentStrategyFactory: _strategies = { "wechat": WechatPay, "alipay": Alipay, "bankcard": BankCardPay, }

@classmethod def get_strategy(cls, payment_type: str) -> PaymentStrategy: strategy_class = cls._strategies.get(payment_type) if not strategy_class: raise ValueError(f"不支持的支付方式: {payment_type}") return strategy_class()

使用方式

def process_payment(payment_type: str, amount: float): strategy = PaymentStrategyFactory.get_strategy(payment_type) return strategy.pay(amount) ```

重构后的代码有什么好处呢？

首先，添加新的支付方式不再需要修改核心逻辑。只需要添加一个新的策略类，并在工厂的策略映射中加入对应的条目。这意味着支付模块对扩展开放、对修改关闭——这正是面向对象设计原则中著名的“开闭原则”。

其次，代码结构更加清晰。每种支付方式的逻辑都被封装在各自的类中，职责分明，易于理解和维护。

第三，更容易进行单元测试。你可以单独测试每一种支付策略，而不需要构建完整的支付环境。

第四，消除了重复代码。验证金额、连接API、执行支付这些公共步骤可以被抽取到基类或模板方法中，进一步减少重复。

这就是设计模式的力量。它不仅仅是让代码能跑，更是让代码跑得漂亮、跑得健壮、跑得易于维护。

从更高的角度看设计模式的价值

让我们把视野再拔高一点，思考一下设计模式对于软件开发和个人发展的深层价值。

第一，设计模式是沟通的桥梁。

当团队中的每个程序员都熟悉设计模式时，代码评审、设计讨论、技术沟通都会变得高效得多。你不需要长篇大论地描述你的设计方案，只需要说“这里我打算用观察者模式来实现消息订阅”，大家立刻就能明白你的意图。这大大降低了沟通成本，减少了误解。

第二，设计模式是代码质量的保障。

经过几十年实践验证的设计模式，蕴含着丰富的经验和智慧。遵循这些模式，相当于站在前人的肩膀上。比如，单例模式虽然简单，但它确保了全局唯一性；工厂模式虽然增加了一些复杂性，但它带来了更好的可扩展性；观察者模式虽然需要额外的基础设施支持，但它实现了真正的松耦合。每一项选择都有其权衡，但至少这些权衡是被广泛理解和接受的。

第三，设计模式是架构演进的基础。

一个好的架构不是一蹴而就的，而是在不断演进中形成的。设计模式就像是建筑中的标准构件，当你需要在系统中添加新功能时，使用正确的模式可以让改动更加平滑，减少对现有系统的影响。理解了设计模式，你就理解了为什么很多系统架构要做这样的设计选择，也为将来自己设计系统架构打下基础。

第四，设计模式是专业成长的阶梯。

从“写代码”到“写好代码”再到“设计系统”，这是程序员成长的必由之路。设计模式处于“写好代码”和“设计系统”之间的关键位置。掌握了设计模式，你就不再只是一个“代码匠”，而是一个能够从更高角度审视代码、思考系统的“软件设计师”。

SOLID原则：设计模式的基石

学习设计模式，不能只学习表面——记住23种模式的名称和结构图。更重要的是理解这些模式背后的设计原则。只有掌握了这些原则，才能真正理解为什么这些模式要这样设计，以及在什么情况下应该使用它们。

在所有的设计原则中，SOLID原则是最核心、最常用的。SOLID是五个设计原则首字母的组合，由Robert C. Martin（也就是我们常说的“Bob大叔”）在21世纪初系统提出。这五个原则分别是：

单一职责原则（Single Responsibility Principle）

定义：一个类应该只有一个引起它变化的原因。

这句话听起来简单，但做到却不容易。什么叫“引起变化的原因”？一个类为什么会有多个“引起变化的原因”？

让我们来看一个反例：

```python class User: def __init__(self, name, email): self.name = name self.email = email

def save_to_database(self):

保存用户到数据库

pass

def send_email(self):

发送邮件

pass

def generate_report(self):

生成用户报告

pass ```

这个`User`类有什么问题？表面上它只是一个用户类，但仔细一看，它实际上承担了三种不同的职责：

• 数据存储（save_to_database）
• 邮件发送（send_email）
• 报告生成（generate_report）

这意味着三种不同的变化都可能要求修改这个类。也许数据库结构变了要改它，也许邮件服务换了要改它，也许报告格式变了也要改它。这么多变化原因都集中在一个类里，就像把所有鸡蛋放在一个篮子里，非常脆弱。

更好的设计是将这些职责分离：

```python

只负责用户数据的类

class User: def __init__(self, name, email): self.name = name self.email = email

负责数据持久化

class UserRepository: def save(self, user: User): pass

def find(self, user_id): pass

负责邮件相关

class EmailService: def send_welcome_email(self, user: User): pass

负责报告生成

class ReportGenerator: def generate_user_report(self, user: User): pass ```

每个类都只有一个变化的原因，职责清晰，职责之间相互独立。这就是单一职责原则的核心思想。

开闭原则（Open-Closed Principle）

定义：软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。

这是什么意思呢？让我们继续用前面的支付例子来说明。

在最初的版本中，每添加一种新的支付方式，都需要修改`process_payment`函数，添加一个新的if分支。这违反了开闭原则——你不得不在原有代码上动手。

而在重构后的版本中，添加新的支付方式不需要修改现有的核心代码，只需要添加新的策略类。这才是符合开闭原则的设计——对扩展开放（可以添加新的支付方式），对修改关闭（不需要修改处理支付的逻辑）。

开闭原则的关键在于抽象。通过引入抽象层（PaymentStrategy接口），我们可以把不变的部分（处理支付的流程）和可变的部分（具体的支付实现）分离。这样变化发生时，我们只需要扩展（添加新类），而不需要修改已经稳定的核心逻辑。

里氏替换原则（Liskov Substitution Principle）

定义：子类对象应该能够在不破坏程序正确性的前提下替换父类对象。

这个原则听起来有些拗口，但它要表达的意思其实很直观：继承关系中，子类应该能够透明地替代父类。

举个例子。假设我们有一个表示几何图形的类层次结构：

```python class Rectangle: def set_width(self, width): self.width = width

def set_height(self, height): self.height = height

def area(self): return self.width * self.height ```

现在我们需要一个正方形类。由于正方形是特殊的矩形（长和宽相等），直觉上我们会