刚学设计模式的人，最容易犯一个错：把它当成”要背下来的 23 个名词”，然后拿着锤子到处找钉子。

这完全跑偏了。

设计模式的价值，从来不在”记住”，而在理解它为什么出现。

设计模式到底解决什么问题

写代码久了你会发现，很多问题会反复出现：

  • 怎么保证一个类只有一个实例？
  • 怎么在运行时切换不同的算法？
  • 怎么让两个模块解耦、互不直接依赖？
  • 怎么在不改老代码的前提下扩展新功能？

这些问题被无数工程师踩过、想过、总结过，最后沉淀成了一套”常见问题的常见解法”——这就是设计模式。

它本质上是一套经验的复用。你不需要自己重新发明轮子，前人已经替你想好了。

把设计模式当”通用语言”

我真正体会到设计模式的价值，是在团队协作里。

假设你在代码评审时看到这样一段话：

“这里建议用策略模式把这块 if-else 拆掉。”

如果你们团队都懂策略模式，这句话一句话就说清楚了，不用解释一大堆背景。

但如果没人懂，你就得说：”你看这里，我们有三种计费方式，现在是 if-else 判断，以后可能还会加第四种、第五种，而且每个分支的逻辑还很长……”

设计模式是工程师之间沟通问题的通用词汇表。它让”复杂的设计意图”可以用一个词精准传达。

这是它最被低估的价值。

三大分类

GoF（Gang of Four）的《设计模式》把 23 种模式分成三类：

1. 创建型（Creational）

解决”怎么创建对象“的问题。

  • 单例、工厂方法、抽象工厂、建造者、原型

核心思想：把”对象的创建”和”对象的使用”分离开，让你可以灵活控制创建过程，而不是到处 new。

2. 结构型（Structural）

解决”怎么把类和对象组合成更大的结构“的问题。

  • 适配器、装饰器、代理、桥接、组合、外观、享元

核心思想：关注类和对象之间的关系，让系统在结构上更灵活、更容易扩展。

3. 行为型（Behavioral）

解决”对象之间怎么交互、怎么分配职责“的问题。

  • 策略、观察者、模板方法、责任链、状态、命令、迭代器、访问者等

核心思想：关注对象之间的通信方式，把行为封装起来，让系统在运行时更容易变化。

一个必须记住的前提

设计模式有个大前提：它是在面向对象语言里，为了应对”变化”而总结出来的。

如果你的代码永远不会变，那设计模式就是过度设计。

所以每次想用某个模式之前，先问自己一句：

这里未来会怎么变？这个模式是让”变化”更容易，还是让”当前代码”更复杂？

设计模式是手段，不是目的。为了用模式而用模式，是典型的坏味道。

我的学习建议

  1. 先理解”为什么”，再记”怎么写”。每个模式都对应一个具体的痛点，找到那个痛点，模式就记住了。

  2. 写一遍代码，不要只看 UML 图。看十遍不如自己敲一遍。

  3. 在真实代码里找模式。Spring 框架里到处都是模板方法、策略、观察者，读框架源码是学模式最好的方式。

  4. 警惕过度设计。新手最大的问题不是”不会用模式”，是”乱用模式”。

后面几篇，我会挑几个最常用、也最容易被问到的模式，逐个拆开讲。先从创建型的单例和工厂开始。