我们来详细梳理23种设计模式的历史背景，这背后是面向对象编程发展的一段关键历程，脉络非常清晰，我们分 起源铺垫 → 核心诞生 → 传播普及 三个阶段来讲，帮你吃透来龙去脉。

一、 诞生前的铺垫：为什么会出现“设计模式”？（1960s-1980s）

23种设计模式不是凭空创造，而是对多年面向对象编程实践的总结，背后是软件工程从“混乱开发”到“规范化开发”的刚需，核心铺垫有3个关键节点：

  1. 面向对象编程（OOP）思想落地，缺乏统一实践标准
    1960s 面向对象思想萌芽（Smalltalk语言雏形），1970s Smalltalk-72/76 正式确立OOP核心概念（类、对象、继承、多态），1980s C++ 把OOP带入工业级开发，越来越多开发者用OOP写复杂系统。
    但问题来了：大家写法五花八门，相同问题有不同解法，代码复用性、可维护性天差地别，比如“怎么保证一个类只有一个实例”“怎么灵活扩展对象功能”，没人总结最优解，新手踩坑无数。

  2. “模式”思想先在建筑领域生根，跨界启发软件工程
    设计模式的“模式”（Pattern）一词，最早来自建筑领域：1977年，建筑大师克里斯托弗·亚历山大出版《建筑模式语言》，提出“建筑模式”—— 总结建筑中反复出现的问题+最优解决方案（比如“客厅采光模式”“街道宽度模式”），能被复用。
    这个思想被软件工程界关注：软件开发中也有大量“反复出现的问题”，能不能像建筑一样，总结成“软件模式”？1987年起，软件工程界开始讨论“软件模式”，为后续23种模式打下思想基础。

  3. 复杂软件系统爆发，倒逼“可复用设计”需求
    1980s末-1990s初，软件规模从“小工具”升级为“大型复杂系统”（比如企业级软件、操作系统），“代码复用”“易扩展”“低耦合”成了核心痛点：修改一个模块牵一发而动全身，新功能开发要重写大量代码，维护成本极高。
    开发者迫切需要一套“现成的设计套路”，解决这些共性问题，而不是每次都从零摸索。

二、 核心诞生：23种设计模式的“封神之作”（1990-1994）

这是最关键的阶段，核心就是**“四人帮（Gang of Four, GoF）”的总结与成书**，23种设计模式正式定型。

  1. 核心人物：四人帮（GoF）
    4位都是资深面向对象开发者，有丰富的大型系统开发经验，核心贡献是把分散的“设计套路”系统化、标准化：

    • 埃里克·伽马（Erich Gamma）：后来参与JUnit、Eclipse开发
    • 理查德·赫尔姆（Richard Helm）
    • 拉尔夫·约翰逊（Ralph Johnson）
    • 约翰·弗利赛德斯（John Vlissides）

  2. 诞生过程：从实践总结到成书，耗时4年
    1990年起，4人基于自己的开发经验，加上梳理当时软件工程界的优秀设计实践，聚焦“面向对象软件的可复用设计”，筛选出最通用、最核心的设计套路：

    • 第一步：筛选标准—— 必须是“反复出现的问题”+“可复用的解决方案”+“不依赖具体语言”，能适配多数OOP场景；
    • 第二步：分类梳理—— 按“解决什么问题”分成3大类（创建型、结构型、行为型），避免混乱；
    • 第三步：完善细节—— 给每种模式定义“核心意图、适用场景、结构角色、优缺点”，让开发者能直接套用。
      1994年，他们的著作《设计模式：可复用面向对象软件的基础》（Design Patterns: Elements of Reusable Object-Oriented Software）正式出版，书中明确提出23种设计模式，这也是23种模式的“官方源头”。

  3. 为什么是23种？不是22也不是24？
    没有绝对的“必须是23种”，核心是**“刚好覆盖面向对象设计的核心共性问题”**：

    • 创建型5种：解决“对象创建”的共性问题（怎么创建、怎么管控、怎么复用）；
    • 结构型7种：解决“类/对象组合”的共性问题（怎么组合更灵活、怎么解耦、怎么优化结构）；
    • 行为型11种：解决“对象交互/职责”的共性问题（怎么通信、怎么分配职责、怎么灵活变更行为）；
      这23种刚好覆盖OOP开发中80%以上的通用设计问题，剩下的要么是场景太小众，要么是可复用性不强，因此没有纳入。

三、 传播与普及：从“小众手册”到“OOP必学标准”（1994至今）

《设计模式》成书初期不算“爆款”，但随着OOP语言普及，逐渐成为软件工程的“圣经”，23种模式也成了行业标准。

  1. 1990s末：Java崛起，让设计模式“落地生根”
    1995年Java发布，纯面向对象设计，且快速占领企业级开发市场。Java的核心类库（比如IO流、集合框架）大量使用23种设计模式（比如装饰器模式、迭代器模式），开发者学Java必学设计模式，23种模式第一次大规模普及。
    例子：Java的BufferedReader是装饰器模式，Iterator是迭代器模式，Runtime是单例模式，直接把模式融入日常开发。

  2. 2000s：多语言适配+框架普及，模式成为“通用知识”

    • 语言层面：C++、C#、Python、PHP等OOP语言，都开始用23种模式解决共性问题，模式不再依赖某一种语言；
    • 框架层面：主流开源框架（Spring、Struts、Hibernate）全程贯穿设计模式（Spring的IOC用工厂模式、AOP用代理模式、事件监听用观察者模式），学框架必须懂模式，进一步巩固其地位。

  3. 发展与争议：模式不是“银弹”，但从未过时
    随着软件开发发展，有人质疑“23种模式过时了”，但核心价值从未变，只是用法更理性：

    • 争议点：部分场景下，现代语言特性（比如Python的装饰器、Java的Lambda）能简化模式实现，无需严格套“模式结构”；
    • 核心价值：模式的本质是**“解耦、复用、可扩展”的设计思想**，而非固定代码结构，23种模式是这些思想的最佳载体；
    • 现状：至今仍是“高级开发者必备知识”，是架构设计、代码评审的核心参考，只是不再“强行套用”，而是“按需使用”。

四、 关键补充：23种设计模式的2个核心定位

  1. 是“总结”而非“发明”：23种模式不是GoF凭空创造，而是对1980s-1990s优秀OOP设计实践的提炼，很多套路在成书前就有人用，只是没人系统化整理；
  2. 是“通用套路”而非“语言规范”：不依赖具体编程语言，不管是Java、C++还是Python，核心思想一致，只是实现细节随语言特性调整。

五、 延伸：设计模式的后续发展

GoF的23种是“基础核心”，后续软件工程界在其基础上延伸出更多细分模式，但都没超越其框架：

  • 企业级模式：比如MVC、分层模式，聚焦大型系统架构；
  • 并发模式：比如生产者-消费者、线程池，解决并发问题；
  • 分布式模式：比如服务注册发现、熔断降级，适配分布式系统；
    这些都是23种基础模式在特定场景的延伸。