设计模式

23种设计模式的核心意图，其实就是它们各自想要解决的最本质的痛点。为了让你更直观地理解，我将这些模式的“核心意图”提炼成了它们最想回答的问题：

🛠️ 创建型模式（5种）

核心意图：解决“如何优雅地把对象造出来”的问题。

模式名称	核心意图（它想解决的问题）
单例模式	“怎么保证全局只有一个实例？” 避免频繁创建销毁、节约资源并保证数据统一（如数据库连接池）。
工厂方法	“怎么让子类来决定造哪个具体产品？” 把对象的实例化推迟到子类，遵循开闭原则，方便扩展新产品。
抽象工厂	“怎么一次性造出一整套相关的家族产品？” 不指定具体类，直接创建一个相关或相互依赖的对象族（如换肤时同时换按钮和窗口）。
建造者模式	“怎么一步步组装一个极其复杂的对象？” 把复杂对象的构建过程拆分成多个步骤，屏蔽内部细节，分步配置属性。
原型模式	“怎么跳过昂贵的初始化，直接复制一个现成的？” 通过克隆已有对象来创建新对象，规避复杂的构造过程（如游戏角色模板复制）。

🏗️ 结构型模式（7种）

核心意图：解决“如何让不同的类或对象更好地组合在一起”的问题。

模式名称	核心意图（它想解决的问题）
适配器模式	“接口不兼容，怎么让它们一起工作？” 充当转换器，不改旧代码的前提下，把一个接口转换成客户端期望的另一个接口。
桥接模式	“怎么让抽象和实现两个维度都能独立变化？” 将抽象部分与它的实现部分分离，避免类爆炸，让两者可以互不影响地扩展。
组合模式	“怎么让客户端无视‘单个对象’和‘整体容器’的区别？” 将对象组织成树形结构（部分-整体），对叶子节点和容器节点提供一致的操作接口。
装饰器模式	“怎么在不改原类的情况下，动态地给对象加功能？” 像俄罗斯套娃一样包装对象，比继承更灵活地扩展职责（如Java I/O流）。
外观模式	“子系统太复杂，怎么提供一个简单的入口？” 为复杂的子系统提供一个统一的高层接口（门面），简化客户端的调用难度。
享元模式	“对象太多导致内存爆满怎么办？” 运用共享技术高效支持大量细粒度的对象，极大减少内存占用（如围棋棋盘的黑白子）。
代理模式	“怎么控制对这个对象的访问？” 找一个替身（代理）来代表真实对象，以此实现权限控制、延迟加载或远程访问。

🚀 行为型模式（11种）

核心意图：解决“对象之间如何高效通信和分配职责”的问题。

模式名称	核心意图（它想解决的问题）
责任链模式	“请求该由谁来处理？怎么避免发送者和接收者耦合？” 把多个处理对象连成一条链，让请求沿着链传递，直到有对象能处理它。
命令模式	“怎么把‘发出请求’和‘执行请求’解耦？” 把请求封装成独立的命令对象，从而支持撤销、重做、排队等高级功能。
解释器模式	“怎么让程序读懂并执行一门自定义的小语言？” 定义语言的语法表示，并建立一个解释器来执行该语言中的句子。
迭代器模式	“怎么在不暴露内部结构的情况下遍历集合？” 提供一种统一的方法顺序访问聚合对象中的各个元素，屏蔽底层数据结构差异。
中介者模式	“对象之间交互太乱怎么办？” 用一个中介对象封装一系列对象的交互，让大家只和中介者打交道，降低多对多的网状耦合。
备忘录模式	“怎么保存对象的历史状态以便随时恢复？” 在不破坏封装性的前提下，捕获对象的内部状态快照，用于后续的撤销/回滚。
观察者模式	“一个对象变了，怎么自动通知所有依赖它的对象？” 建立一对多的依赖关系，主体状态改变时，所有订阅者都会收到通知并自动更新。
状态模式	“怎么消除大量的 if-else 状态判断语句？” 允许对象在内部状态改变时改变它的行为，让状态转换逻辑分布到各个状态类中。
策略模式	“怎么在运行时随意切换一组算法？” 定义一系列可互相替换的算法并封装起来，使算法的变化独立于使用它的客户。
模板方法模式	“怎么固定算法骨架，但把具体步骤留给别人实现？” 在父类中定义好流程的固定步骤，将可变的具体细节延迟到子类中去实现。
访问者模式	“数据结构不变，但想经常增加新的操作怎么办？” 在不修改现有类结构的前提下，为该对象结构中的各元素增加新的操作。

掌握这些核心意图后，当你遇到具体的业务痛点时（比如“我想换个算法但不想改主流程”），就能迅速联想到对应的模式（策略模式）。