一、设计模式导论：软件危机的根源、设计模式的定义与历史（GoF）、模式的四大要素
大家好，我是你们这门课的老朋友。今天咱们聊聊设计模式的导论部分。说实话，我刚开始接触这玩意儿的时候，也觉得它挺玄乎的。什么模式不模式的，不就是写代码吗？后来踩的坑多了，才明白——嗯，这玩意儿是真能救命。
1.1 软件危机的根源：我们到底在怕什么？
先说说软件危机。这个词听起来挺吓人，其实说白了就是：软件越来越复杂，人越来越搞不定。
我记得刚入行那会儿，带我的老工程师跟我说过一句话：「写代码容易，改代码难。」我当时不信。后来自己接手了一个遗留系统，光一个模块就三千多行，全是 if-else 嵌套。改一个 bug，能引出三个新 bug。你想想看，这滋味好不好受？
为什么会这样？我总结了几点：
- 需求变化太快——今天说要加个功能，明天说要改逻辑。代码写死了，改起来就痛苦。
- 沟通成本太高——你写的代码，别人看不懂。别人写的代码，你也不想看。
- 复用性太差——同样的逻辑，换个项目就得重写。说白了就是没有积累。
- 维护成本爆炸——代码越堆越多，最后谁都不敢动。
我在一个电商项目中就吃过这个亏。当时为了赶工期，大家各写各的，没有统一的设计思路。结果上线后，每次加功能都要改一大片代码。有一次改了个支付接口，结果把订单查询的逻辑也带崩了。你说冤不冤？
1.2 设计模式的定义与历史：GoF 那群人干了什么？
设计模式这个概念，最早不是软件领域的。建筑大师 Christopher Alexander 在 70 年代就提过，说建筑里有一些「反复出现的问题」和「对应的解决方案」。后来软件界的人一听——哎，这个思路好！
1994 年，有四个人——Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides——出了一本书，叫《Design Patterns: Elements of Reusable Object-Oriented Software》。这四个人后来被称为 GoF（Gang of Four，四人帮）。
这本书里总结了 23 种设计模式。说白了，就是他们从大量项目中提炼出来的「最佳实践」。我个人习惯把这 23 种模式分成三类：
| 分类 | 作用 | 例子 |
|---|---|---|
| 创建型模式 | 解决对象怎么创建的问题 | 单例、工厂、建造者 |
| 结构型模式 | 解决类和对象怎么组合的问题 | 适配器、代理、装饰器 |
| 行为型模式 | 解决对象之间怎么交互的问题 | 观察者、策略、模板方法 |
你可能会问：为什么是 23 种？不是 22 种，也不是 24 种？其实后来也有人补充过，但这 23 种是最经典、最通用的。我建议初学者先把这 23 种吃透，再去碰那些变种。
1.3 模式的四大要素：模式名、问题、解决方案、效果
每个设计模式都有四个核心要素。我习惯把它们叫做「模式的身份证」：
- 模式名——就是一个名字，方便大家沟通。比如「单例模式」，你说出来，别人就知道你在说什么。
- 问题——这个模式要解决什么场景下的什么问题。比如「如何保证一个类只有一个实例？」
- 解决方案——具体怎么实现。包括类图、代码结构、交互流程等。
- 效果——用了这个模式之后，有什么好处，有什么坏处。没有银弹，每个模式都有 trade-off。
举个例子，单例模式：
- 模式名：Singleton
- 问题：系统中某个类只需要一个实例，比如配置管理器、日志记录器。
- 解决方案：把构造函数私有化，提供一个静态方法返回唯一实例。
- 效果：节省资源，保证全局唯一。但也会让代码耦合变高，测试起来麻烦。
我在项目中遇到过一个问题：一个日志模块，多个地方都在 new 实例，结果日志文件被反复打开关闭，性能差得要命。后来改成单例，问题就解决了。但要注意，单例不是万能的。滥用单例，会让你的代码变成一团乱麻。
1.4 知识体系总览
下面这张图，是我自己整理的。它把设计模式的核心逻辑串起来了。你一看就明白：模式不是孤立的，它们之间有关系。
你看，这张图把设计模式的核心逻辑讲清楚了。从上到下，先分三大类，再拆四大要素。你以后学任何一个模式，都可以用这个框架去套。
好了，这一章就到这里。设计模式不是一天能学会的，但只要你理解了它的本质——「用经验解决问题」——你就已经上路了。下一章我们聊聊单例模式，那个我踩过最多坑的模式。到时候再细说。
公众号:蓝海资料掘金营，微信 deep3321