设计模式实战手册：五大原则、UML类图与六个高频模式代码详解

简介：王桂林老师整理的设计模式学习讲义，以PDF形式呈现，面向需要系统掌握设计模式的软件开发者、计算机专业学生及初级工程师。内容以经典GOF理论为主线，讲解设计模式的历史渊源与“名称—问题—解决方案—效果—结构”的陈述框架，并结合有代表性的书籍给出学习建议。后续重点剖析单一职责、开闭、依赖倒置等面向对象设计核心原则，通过问题由来与解决方案帮助读者理清重构思路，提升代码的可扩展性与可维护性。资源为单个PDF文件，大小3.09MB，适合离线阅读与碎片化学习。目前已有157人学习下载，这份简明讲义可作为入门设计模式的轻量参考。

1. 设计模式这份PDF：比目录更有用的、能直接手写复现的代码讲义

设计模式是被讨论最多、背得最快、用得最乱的一套软件工程概念。很多人把二十多种模式的名称倒背如流，可真要动手写代码时，还是忍不住用 if-else 一路堆到底。这份设计模式 PDF 的特别之处在于：它不满足于"定义加类图"的教科书式讲法，把五大原则、六种 UML 类图关系和六个高频模式都配了可以直接上手的示例代码，而且场景全都落在日常项目里——全局配置、事件监听、算法切换、资源按需加载。适合谁用？适合不想停留在"知道模式名"、想真正把模式写进项目的开发者。我的建议很直接：照着这份讲义把单例、观察者、策略、代理、装饰各手写一遍，比背三遍目录有用得多。

2. 设计模式五大原则：从背定义到拿去评审代码

2.1 单一职责与开闭原则：两个最常见的评审标尺

单一职责原则（SRP）的定义一句话就能说完：一个类只负责一项职责，或者说只有一个引起它变化的原因。但"一项职责"这个边界在实际代码里非常模糊。举个例子，一个订单类既负责从数据库读订单，又负责把订单渲染成 HTML。数据库表结构一变要改它，前端页面结构一变也要改它。两个变化方向因为耦合在一个类里，任何一端的改动都可能把另一端带崩。判断标准不是"类够不够小"，而是"它有几个变化的来源"。

我一般会给每个类写一句职责描述：如果这句话里同时出现了"并且""同时"这类连接词，说明职责开始膨胀了。比如"订单类负责解析数据并且渲染界面"，这句话本身就暴露了问题。PDF里把解决方案概括成两条：把大类拆成功能更单一的小类，或者用组合聚合把相关类组织成松散耦合的结构。实操上优先做前者，因为组合聚合的引入通常要伴随更清晰的生命周期管理，小步拆分更安全。

开闭原则（OCP）比 SRP 更抽象：对扩展开放，对修改关闭。意思是需求新增时，应该通过新增代码而不是修改已有代码来实现。很多初学者把 OCP 理解成"加了需求不能动旧代码"，这其实不准确。正确理解是：经常变化的业务点应该预留扩展位，让旧代码的稳定骨架尽量不动，变化的部分通过组合或继承接进来。策略模式、装饰模式本质上都是 OCP 的产物。

用一段 TypeScript 代码展示从违背到遵循 OCP 的差异。假设一个订单折扣服务：

// 违背OCP：每次加新折扣类型都要改这个函数 class OrderDiscount { calculate(type: string, amount: number): number { if (type === 'none') return amount; if (type === 'vip') return amount * 0.9; if (type === 'season') return amount * 0.8; return amount; // 新折扣类型来了，继续往下加if } }

这种写法的致命点在于：每增加一种折扣，OrderDiscount 类就要改一次，所有调用方都依赖这个函数内部的 if 判断，测试用例也得跟着膨胀。遵循 OCP 的做法是把算法族拆开，交给策略接口：

interface DiscountStrategy { apply(amount: number): number; } class NoDiscount implements DiscountStrategy { apply(amount: number): number { return amount; } } class VipDiscount implements DiscountStrategy { apply(amount: number): number { return amount * 0.9; } } class OrderContext { constructor(private strategy: DiscountStrategy) {} setStrategy(strategy: DiscountStrategy): void { this.strategy = strategy; } calc(amount: number): number { return this.strategy.apply(amount); } }

改动点从"订单计算逻辑"变成了"策略的选择和组装"。以后要加"双十一五折"，新建一个类传进 OrderContext，关键计算路径一行都不用动。参数方面注意：OrderContext 持有的是 DiscountStrategy 接口，不是具体实现类，调用方决定传哪个策略进来，这就是 OCP 和策略模式的结合。但也不能教条化——如果新增频率低、逻辑固定，没必要为 OCP 硬拆成七八个类，拆出来的策略长期不变化反而增加理解成本。

2.2 依赖倒置、接口隔离与里氏替换：代码示范怎么读

依赖倒置原则（DIP）在 PDF 里有专门的代码示范，值得逐行读。它的大意是：高层模块不应该依赖低层模块，两者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。翻译成大白话：业务层依赖的是"存储"这个抽象概念，而不是"MySQL 数据库"或"本地文件"这种具体实现，这样换存储方案时业务层不用跟着动。

// 低层模块：具体存储实现 class MysqlStorage { save(key: string, value: string): void { console.log(`INSERT INTO t(key, value) VALUES(${key}, ${value})`); } } // 高层业务：直接new了MysqlStorage，违背DIP class UserServiceBad { private storage = new MysqlStorage(); saveUser(id: string, data: string): void { this.storage.save(id, data); } } // 抽象接口 interface KVStorage { save(key: string, value: string): void; } // 高层业务依赖抽象 class UserService { constructor(private storage: KVStorage) {} saveUser(id: string, data: string): void { this.storage.save(id, data); } } // 替换实现不影响UserService const service = new UserService(new MysqlStorage()); // 以后换成Redis：new UserService(new RedisStorage())

UserServiceBad 的问题不只在测试和替换上——当 MysqlStorage 的构造函数需要配置连接参数时，UserServiceBad 也得跟着改，而依赖 KVStorage 接口的 UserService 完全无感。这段代码里有个值得留意的参数：KVStorage 接口只暴露 save 方法，不暴露连接、事务等细节，这已经带出了接口隔离的雏形。

接口隔离原则（ISP）说的是客户端不应该依赖它不需要的接口。典型反例是一个大接口塞了十几个方法，调用方只用到其中两个，却被迫依赖全部。解决方法是按"客户端角色"把大接口拆成几个小接口——谁使用谁定义，而不是谁方便谁定义。拆分粒度同样不是越细越好，过细的接口会让组合成本上升，适度即可。

里氏替换原则（LSP）通常放在继承场景里讨论：子类必须能替换父类且不影响程序正确性。PDF 给了代码示范，核心意思是不要为了复用代码而随便继承。"正方形继承矩形"是经典反例：矩形宽高各自独立，正方形要求宽高相等，在 Setter 里加约束后，父类能跑的逻辑在子类就跑不对了。判断 LSP 是否被违反有一个实用技巧：把父类实例全部替换成子类实例跑一遍测试，看行为是否一致。子类覆盖父类方法后抛出额外异常、改变返回值语义、对参数施加更严格的前置条件，都属于违反 LSP。实际项目里最隐蔽的是"继承后重写方法时悄悄忽略部分逻辑"，编译不报错，但调用方以为是老行为，实际拿到了新行为。因此遇到"只想复用一段代码"的情况，优先考虑组合而不是继承，这也是很多模式都以接口组合为主的原因。

3. UML 类图六种关系：箭头、强弱与生命周期的一次分清

3.1 从面向过程到面向对象：类间关系为什么重要

面向过程时代，代码里主要是函数调用，数据在函数之间传递，"关系"就是谁调用谁。面向对象时代，类和类之间的关系变得复杂：一个类可能继承另一个类，可能持有另一个类的引用，也可能只是在某个方法里临时用到另一个类。这些关系的强弱、生命周期归属、变化传播范围完全不同。PDF 里把类图关系分成纵向和横向两组：纵向是泛化和实现，管"是什么"；横向是组合、聚合、关联、依赖，管"有什么、用一下"。这个分法很实用，先把大方向定住，再记六种箭头的细节。

记箭头有个顺序技巧：先看三角和菱形。空心三角的是纵向关系，指向父类或接口；菱形的是横向关系，实心菱形和空心菱形的差别只在生命周期上。具体规则见下表。

这张表可以直接当速查卡。依赖是最弱的关系，几乎每段代码都有；泛化和实现是最强的静态关系，类一旦定下来就不太会变；组合和聚合是判题时最容易混的一组，重点看生命周期归属。

3.2 泛化、实现与关联：三个容易的，先说清

泛化就是继承，表示 is-a 关系。写起来最简单：

class Animal { constructor(public name: string) {} speak(): string { return '...'; } } class Dog extends Animal { speak(): string { return 'Woof'; } }

实现关系把"能力约定"和"具体实现"分开，接口只定义行为，类负责落地：

interface Runnable { run(): void; } class Robot implements Runnable { run(): void { console.log('robot runs'); } }

关联关系是持久的引用关系，比如一个客户类持有订单类集合，订单类又持有商品类。关联和聚合的差别在于：关联双方是平等的，没有明显的整体-部分语义；聚合则有明确的整体和部分。早期代码里很容易把"类里有个成员变量"都喊成聚合，实际上只有整体-部分语义明显才算聚合，普通成员引用就是关联。一个类里持有另一个类的引用，且双方各管各的生命周期，画实线普通箭头就对了。

3.3 组合与聚合的区分：生命周期视角和两个代码片段

组合和聚合是六大关系里最常见的翻车点。区分只有两条：

• 组合：部分的创建和销毁由整体负责。比如人和心脏，人 new 出来心脏跟着创建，人销毁心脏也跟着销毁。
• 聚合：整体可以创建，但部分是从外部传入的独立对象。比如班级和学生，学生先存在，被加进班级；班级解散，学生还在。

下面用代码对照：

// 组合：World在内部new了Light，Light的生命周期由World管理 class Light { on(): void { console.log('light on'); } } class World { private light = new Light(); // 组合：整体内部创建部分 startDay(): void { this.light.on(); } } // 聚合：Team通过setter得到成员，成员对象是外部创建的 class Member { constructor(public name: string) {} } class Team { members: Member[] = []; addMember(m: Member): void { this.members.push(m); } // 聚合：外部传入，Team不负责销毁 } const alice = new Member('alice'); const team = new Team(); team.addMember(alice); // alice在team之外仍然存在

判断方法很直接：看对象在哪个类里 new 出来的。整体类内部 new 的是组合，外部传进来的是聚合。这个判断方法覆盖了绝大多数代码场景。但要注意语言层面的语法和语义不完全等同——JavaScript/TypeScript 里对象只要还有引用就不会被回收，"销毁"更多是逻辑上的责任划分。画类图时把这种责任划清，比背概念有用得多。类图关系本质上回答的是"谁创建谁、谁持有谁、谁依赖谁"，想清楚这三个问题，UML 的箭头就不会画错。

4. 单例、观察者、策略：三个可以直接抄进项目的模式模板

4.1 单例模式：全局配置与 Cocos 里的导演

单例的目标是保证一个类只有一个实例，并提供一个全局访问点。但全局访问点是一把双刃剑：它很方便，可任何代码都能调用；如果单例里存了状态，状态就会泄漏到所有调用点。PDF 里第一个实战例子是全局配置文件，这是最稳的单例用法——配置对象基本只读，不存在并发写的问题。第二个例子是游戏引擎里的导演类：场景管理、暂停恢复、场景切换这些全局操作天然只需要一个入口。如果你的项目里也有类似的"全局且唯一"对象，单例是可以直接落地的方案。

TypeScript 里一个最简单的懒加载单例：

class ConfigManager { private static instance: ConfigManager; private settings: Record<string, string>; private constructor() { // 私有构造，外部不能new this.settings = { version: '1.0.0' }; } static getInstance(): ConfigManager { if (!ConfigManager.instance) { ConfigManager.instance = new ConfigManager(); } return ConfigManager.instance; } get(key: string): string { return this.settings[key]; } } const cfg = ConfigManager.getInstance(); console.log(cfg.get('version'));

注意几个点：私有构造函数在编译期阻止外部 new，但运行时仍可绕过，这属于语言层面的限制；Java/C# 里懒加载的 getInstance 在并发环境下可能 new 出多个实例，常见解法是双重检查锁或在静态初始化块里直接创建；TypeScript 单线程环境没有这个竞态问题。单例的测试难题绕不开——业务类直接调 getInstance 会很难模拟，因此我一般会把单例对象通过构造函数注入业务类，业务类不知道对象是不是单例，将来替换也容易。

注意：单例是唯一一个需要"慎用"结论的模式，它解决的是"全局唯一实例怎么可靠创建和访问"，不是"某个东西所有人都能随便拿"。

在游戏开发里，导演的封装思路通常是：用静态方法获取引擎的导演实例，再把游戏自己的全局状态放进一个单例托管类，场景切换时负责清理不需要的临时数据。全局状态不是不能有，而是要明确归谁管。

4.2 观察者模式：事件监听与 _eventDispatcher

观察者解决"一个对象状态变化，多个对象需要同步响应"的一对多问题。PDF 的引例是事件驱动场景：把"通知谁"这件事从被观察者里拿出来，让订阅者自己决定要不要听、什么时候听。游戏引擎里的 EventListener 与 _eventDispatcher 就是这个模式的引擎级落地：事件监听器（观察者）注册到事件分发器（主题）上，场景内任意对象都可以发事件，监听者收到回调再各自处理。

自己实现一个极简事件总线：

type EventCallback = (data: unknown) => void; class EventDispatcher { private listeners: Map<string, Set<EventCallback>> = new Map(); on(event: string, cb: EventCallback): void { if (!this.listeners.has(event)) { this.listeners.set(event, new Set()); } this.listeners.get(event)!.add(cb); } off(event: string, cb: EventCallback): void { this.listeners.get(event)?.delete(cb); } emit(event: string, data: unknown): void { this.listeners.get(event)?.forEach(cb => cb(data)); } } const bus = new EventDispatcher(); const onDamage = (data: unknown) => { const { hp } = data as { hp: number }; console.log(`玩家掉血，当前hp=${hp}`); }; bus.on('player:damage', onDamage); bus.emit('player:damage', { hp: 80 }); bus.off('player:damage', onDamage);

参数要说明清楚：on 负责注册，off 必须接收同一个函数引用才能移除。如果注册时用了匿名箭头函数，之后就拿不到引用来 off，这是观察者模式最典型的内存泄漏来源。emit 遍历当前监听器集合，遍历过程中集合如果被修改，行为可能不符合预期，生产级实现一般会对监听器列表做快照。TypeScript 的 unknown 类型需要显式转换，也是很多从 Java 转过来的开发者不习惯的地方。在游戏引擎的节点系统里，EventListener 的生命周期通常绑定在节点上，节点销毁时移除监听；如果忘了在节点销毁回调里 off，场景切换几次后回调会越积越多，重复触发就来了。

4.3 策略模式：算法族替换与档位设计

策略模式解决"同一类行为有多种算法，且算法可能在运行时切换"的问题。PDF 给了两个场景：计算器的运算算法设置，和汽车发动机档位切换。这两个例子的共同点是：行为本身（做运算、输出动力）不变，具体算法（加减乘除、1 到 5 档）可以替换。策略模式把这些算法各自封装成类，让它们在运行时互相替换，调用方完全不需要关心内部实现。

用汽车档位写一段示范：

interface GearStrategy { drive(): string; } class FirstGear implements GearStrategy { drive(): string { return '爬坡，扭矩大，速度低'; } } class FifthGear implements GearStrategy { drive(): string { return '高速巡航，省油'; } } class Car { constructor(private gear: GearStrategy) {} shiftGear(gear: GearStrategy): void { this.gear = gear; } run(): void { console.log(this.gear.drive()); } } const car = new Car(new FirstGear()); car.run(); // 爬坡，扭矩大，速度低 car.shiftGear(new FifthGear()); car.run(); // 高速巡航，省油

和 if-else 相比，策略模式的改动点集中在新增策略类上，Car 类不随档位数量的增长而变化。代价是类数量变多：十个档位就是十个类。实际项目里的常见做法是：策略数量在三个以内且后续不会增加时，用 switch 就够了；策略数量多且可能持续增加时才上策略模式。也可以把策略类内部再合并，用配置驱动来避免膨胀。策略模式与状态模式结构高度相似，区别在于策略由外部替换，状态由对象内部根据条件迁移。如果发现代码里策略被内部逻辑反复切换，那更可能是状态模式，就用错了。

5. 代理与装饰：高频误用与避坑排查手册

5.1 代理模式：虚代理、智能代理、保护代理

代理模式的核心是"为另一个对象提供一个替身或占位符，以控制对这个对象的访问"。PDF 把代理分成三类：虚代理（延迟加载）、智能代理（附加访问逻辑）、保护代理（权限控制）。虚代理最经典的应用是图片懒加载：真正的图片对象很重，先用轻量代理占位，等真正需要渲染时才加载原图。智能代理像是一个拦截器，在访问真实对象前打日志、做访问计数、查缓存。保护代理则在权限校验通过后才放行。

用虚代理写一个最简版本：

interface Image { display(): void; } class RealImage implements Image { constructor(private path: string) { console.log(`加载大图: ${this.path}`); // 模拟重量级加载 } display(): void { console.log(`显示图片: ${this.path}`); } } class LazyImageProxy implements Image { private realImage?: RealImage; constructor(private path: string) {} display(): void { if (!this.realImage) { this.realImage = new RealImage(this.path); // 首次访问才真正加载 } this.realImage.display(); } } const img = new LazyImageProxy('/assets/hero.png'); img.display(); // 第一次触发加载 img.display(); // 第二次直接显示，不再加载

代理的意义在于把"何时创建真实对象"的控制权收进代理里，调用方完全无感知。代理和单例、工厂配合时也常见：代理内部用缓存或对象池来复用真实对象，进一步降低资源开销。装饰和代理都用了包装手法，但后面会讲到，意图完全不同。

5.2 装饰模式：包装器的叠加艺术

装饰模式解决"在运行时动态给对象叠加职责"的问题。PDF 里的咖啡加糖、加奶场景非常典型，每种调料是一个装饰器，包裹在原始咖啡对象外面，最终计算价格和描述。

interface Coffee { cost(): number; desc(): string; } class PlainCoffee implements Coffee { cost(): number { return 5; } desc(): string { return '普通咖啡'; } } class MilkDecorator implements Coffee { constructor(private coffee: Coffee) {} cost(): number { return this.coffee.cost() + 2; } desc(): string { return `${this.coffee.desc()}+牛奶`; } } class SugarDecorator implements Coffee { constructor(private coffee: Coffee) {} cost(): number { return this.coffee.cost() + 1; } desc(): string { return `${this.coffee.desc()}+糖`; } } let coffee: Coffee = new PlainCoffee(); coffee = new MilkDecorator(coffee); coffee = new SugarDecorator(coffee); console.log(coffee.desc()); // 普通咖啡+牛奶+糖 console.log(coffee.cost()); // 8

从这里能清楚看到装饰模式的代价：装饰器层层包裹后，描述字符串的组装顺序依赖装饰顺序，而 cost 计算是逐层累加。如果同一个对象被装饰了两遍，行为会重复叠加。另一个要点是：装饰器接口和被装饰对象接口一致，调用方无法感知是否有装饰层，这也是它和代理长得像的原因。调试时逐层展开包装，看哪一层出了问题，比在脑子里推断组合顺序更靠谱。

5.3 避坑排查：代理与装饰的五个常见问题

下面是我在练习和项目里实际踩过或看到过的坑，每条按现象、原因、解决整理。

• 现象：代理和装饰的结构图几乎一样，写代码时不知道该用哪个。原因：两者都用了"包装"手法，都持有一个真实对象引用。解决：按意图判断。代理控制访问（延迟、权限、日志），不改变核心行为；装饰增强行为（加功能、加价格、加日志输出），不关注怎么拿到对象。如果既想控制访问又想增强功能，可以组合使用两个模式，而不是二选一。

• 现象：装饰器叠加后，行为顺序和预期不符，比如日志先于鉴权打印，或者多个装饰器互相覆盖。原因：装饰器的执行顺序由装饰顺序决定，而代码阅读顺序往往是从下往上的，视觉顺序和执行顺序不一致。解决：叠加装饰器时先明确执行链是"外层先执行"还是"内层先执行"，把最关键的行为放到最外层；装饰器内部尽量只做增量叠加，不要修改被包装对象的状态。

• 现象：代理模式下真实对象被创建了不止一次，资源开销没降下来。原因：虚代理的懒加载逻辑里，真实对象引用的判断条件写错了，多个调用同时进入 if 分支。解决：在代理内部用缓存字段先检查再创建；多线程环境还要加同步控制。JS/TS 单线程没有竞态，但要注意异步场景下的并发入口，比如两个异步任务同时触发 display。

• 现象：Coffee 例子叠加顺序不同，价格却一样，怀疑装饰没生效。原因：cost 是简单累加，顺序对最终数值没影响，但 desc 拼接顺序有影响，视觉上会搞反组合关系。解决：给装饰器补一个"层级"字段，或者在描述输出前统一烘焙成数组，按固定顺序拼接，避免视觉歧义。

• 现象：把代理当成万能封装，所有类都套一层，调用栈深了四层，调试困难。原因：代理增加了间接层，这是成本不是免费的。解决：只对有明确诉求（懒加载、权限、缓存、远程调用）的对象加代理，代理方法尽量透传参数，不做隐式改变，让调用方对"经过了代理"这件事保持可感知。

PDF 里的"延深阅读"部分还提过，装饰模式本质是链式包装，调试时可以打印每一层装饰器的类名来确认包装顺序。这种做法在排查多层装饰问题时比单步调试更快。

6. 进阶内化技巧：用"一句话加一张类图"验证模式掌握度

对于一个刚下载这份 PDF 的开发者，我推荐一个验证自己是否真正掌握某个模式的方法，三步走：写一句话、画一张图、敲一段代码。一句话说清这个模式解决什么问题；一张最小类图画清模式里的核心角色；一段二十行内的代码跑通它。判断标准很明确：如果你无法用一句话说清它解决的是什么，就说明还没掌握它。

举例：

• 单例解决的是"全局唯一实例怎么可靠地创建和访问"。
• 观察者解决的是"状态变化后怎么把通知发给多个订阅者而不产生耦合"。
• 策略替代的是"用 if-else 不断膨胀的算法判断"。
• 装饰替代的是"用继承静态叠加职责"。
• 代理替代的是"直接访问真实对象时伴随的副作用"。

类图怎么画？每个模式只画最核心的两三个角色。比如观察者就画 Subject 和 Observer，中间的"注册"箭头标出来就能说明问题，不需要把十几种变体都画上。图是为了帮自己理清角色边界，不是交作业。

最后一步，从 PDF 里找一个场景，用学到的模式重构一段自己项目里的已有代码。比如把一段多分支的运费计算改成策略模式，把"玩家死亡逻辑"改成观察者事件，记录改动行数和行为差异。改完你会发现，理解一个模式最有效的动作不是看书，而是真的替换掉一段代码。从那以后我每次拿到一份新框架的源码，都会先标出里面的观察者、策略和装饰出现的位置，再强制自己走一遍"一句话加一张类图加一段最小 Demo"的流程，翻车概率明显降低。这套方法同样适用于这份 PDF——别急着把所有模式一口气看完，每周末认真吃透一个，配合手写 Demo，比整本翻三遍有用得多。希望帮到你。

本文还有配套的精品资源，点击获取