一、设计模式概述：什么是设计模式、设计模式的分类、为什么需要设计模式

大家好，我是你们的老朋友。今天咱们来聊聊设计模式这个话题。说实话，我刚开始接触设计模式那会儿，也觉得这东西挺玄乎的——不就是一些套路吗？后来在项目里摔过几次跟头，才真正体会到它的价值。

1.1 什么是设计模式？

设计模式，说白了就是一套被反复使用、多数人知晓的代码设计经验总结。它不是某个天才一拍脑袋想出来的，而是无数程序员在实战中踩坑、填坑、再踩坑之后沉淀下来的最佳实践。

我记得有一次接手一个老项目，代码里到处都是if-else嵌套，改一个功能要翻遍十几个文件。我当时就想：要是当初用点设计模式，也不至于这么痛苦。嗯，这就是设计模式要解决的问题——让代码更灵活、更易维护。

你可能会问：这和算法有什么区别？算法解决的是“怎么做”的问题，比如排序、查找。而设计模式解决的是“怎么组织代码”的问题，比如对象怎么创建、类之间怎么通信。两者维度不同。

1.2 设计模式的三大分类

设计模式按照用途可以分为三类：创建型、结构型、行为型。这个分类是GoF（Gang of Four，四人帮）在1994年提出的，到现在依然是业界标准。

分类	关注点	典型模式	我常用的场景
创建型	对象的创建机制	单例、工厂、建造者	数据库连接池、配置管理
结构型	类与对象的组合	适配器、代理、装饰器	第三方SDK适配、日志增强
行为型	对象间的职责分配	观察者、策略、模板方法	事件驱动、算法切换

创建型模式解决的是“怎么把对象创建得优雅”。比如单例模式，保证一个类只有一个实例。我在做配置管理模块时就用过——整个系统只需要一份配置，创建多个反而会乱套。

结构型模式解决的是“怎么把类和对象组合成更大的结构”。比如适配器模式，让两个不兼容的接口能一起工作。我曾经对接过一个老系统的API，接口参数对不上，用适配器包了一层就搞定了。

行为型模式解决的是“对象之间怎么协作”。比如观察者模式，一个对象状态变化，其他对象自动收到通知。做消息推送系统时，这个模式简直是标配。

1.3 为什么需要设计模式？

这个问题我问过很多新人。有人说是为了“显得专业”，有人说是面试要考。其实都不是。真正的原因就三个字：省力气。

你想想看，一个项目从零开始写，到后期维护，哪个阶段最费时间？不是写代码，是改代码。设计模式就是让你改代码的时候少掉头发。

具体来说，设计模式有这几个好处：

• 复用经验：不用自己从头摸索，直接套用成熟方案。我曾经在三个项目里用了同一个工厂模式，每次改改参数就行，省了不少事。
• 提高可读性：团队里大家都懂设计模式，看到代码就知道意图。比如看到单例，就知道“哦，这里要全局唯一”。不用再写一堆注释解释。
• 降低耦合：模式提倡“面向接口编程”，而不是“面向实现编程”。这样换实现的时候，改一行代码就够了。
• 方便扩展：好的设计模式预留了扩展点。比如策略模式，加一个新策略只需要新增一个类，不用改原有代码。

1.4 设计模式的知识体系

下面这张图是我自己整理的，把设计模式的核心脉络画出来了。你可以把它当作学习地图。

从这张图可以看出，设计模式不是孤立的。它们之间有关联，甚至有些模式可以组合使用。比如工厂模式经常和单例模式一起用——工厂本身可以是单例的。

1.5 什么时候该用设计模式？

这个问题比“怎么用”更重要。我个人的经验是：不要提前设计，等代码出现坏味道再重构。

什么叫坏味道？比如：

• 一个类里塞了太多职责（上帝类）
• 修改一个功能要改好几个类
• if-else嵌套超过三层
• new关键字满天飞，创建逻辑散落各处

遇到这些情况，就可以考虑用设计模式来重构了。我曾经接手过一个支付模块，里面用if-else判断了十几种支付方式。后来用策略模式一重构，每种支付方式一个类，新增支付方式只需要加一个类，改一行注册代码就行。嗯，这才是设计模式该有的样子。

1.6 学习设计模式的正确姿势

我见过很多人学设计模式，上来就背UML图、记类名。结果面试能答上来，写代码还是老样子。我的建议是：

1. 先理解问题：这个模式解决的是什么痛点？没有它的时候代码会写成什么样？
2. 再看解决方案：模式是怎么组织的？核心思想是什么？
3. 最后动手写：找一个小场景，自己实现一遍。不用管UML画得漂不漂亮，代码能跑通就行。
4. 在项目中应用：遇到类似场景，试着用模式重构。哪怕只改一个模块，也比纸上谈兵强。

说白了，设计模式是“练”出来的，不是“背”出来的。你写十遍单例，比看十本书都管用。

---

好了，这一章就聊到这儿。设计模式是个大话题，咱们后面会一个一个拆开来讲。记住：模式是工具，解决问题才是目的。