设计模式三大分类：创建型、结构型、行为型如何判断与选用

大概每个学设计模式的人都背过一句话：创建型模式解决对象创建问题，结构型模式解决类与对象组合问题，行为型模式解决对象协作问题。但真到用的时候，很多人还是会懵——拿到一个需求，不知道往哪一类里想。前两天群里有人问我：创建型、结构型、行为型模式分别解决什么问题？我答完之后发现，真正值钱的不是那一句分类，而是“你遇到什么信号，就知道该去哪个分类里找答案”。这篇文章想把这套判断方法完整讲一遍，也会聊聊最近在多Agent系统设计里看到的设计模式影子。内容对准备面试、写设计模式大作业，或者正在研究智能体架构的朋友，应该都有点用。

1. 创建型模式管的不是“怎么new”，而是“该不该让业务代码拿到构造器”

1.1 直接new带来的三个隐患

我刚开始写Java时，觉得new挺好的，简单直白。后来做了几个中大型项目，发现直接new一个高级对象的代价会一点点暴露。拿数据库连接举例：

java复制DatabaseConnection conn = new DatabaseConnection(
    "127.0.0.1", 3306, "root", "123456", 100
);

看着没啥问题，但一旦这个对象被十几个Service使用，麻烦就来了：

• 数据库地址、账号、连接池大小散落在各处，改配置要全局搜索。
• 每个调用方都承担了构造细节；一旦构造函数增加超时参数，所有调用方都要跟着改。
• 无法在创建前后做统一处理，比如每个连接创建之前要加载驱动，创建之后要预热连接池。

创建型模式要解决的核心问题，就是“实例化”这个动作不该由业务调用方负责。它应该被下沉、封装、统一管理，让业务代码只关心“我要一个满足条件的对象”，而不关心这个对象是怎么被拼出来的。

1.2 六种创建型模式各自拿走哪个环节

创建型模式一共有六个：单例、工厂方法、抽象工厂、建造者、原型。每一种都对应一个具体的“创建变化点”：

注意：创建型模式管的是“创建”，不是“结构”。很多初学者会把工厂和策略搞混，因为两个都能“去掉if else”，后面我会单独讲怎么区分。

1.3 什么时候真的需要抽象工厂？我踩过的坑

抽象工厂是创建型里被误解最多的一个。我曾经做一个跨平台报表组件，需要画不同风格的表格、图表、导出按钮。一开始偷懒，写一个ReportFactory，里面根据平台类型返回一个组件。结果产品说“Windows风格报表配Windows风格按钮”，我却发现返回的表格是Windows风格，按钮是Linux风格，因为组件工厂拆得太散。后来改成抽象工厂，每个平台一个具体工厂类，保证“Windows报告工厂”出的三件套是同一套风格。

踩完之后我总结：如果你要创建的是一族必须成套使用的对象，才需要抽象工厂；如果只是单个对象有多种实现，工厂方法就够了。滥用抽象工厂只会让类爆炸。还有建造者模式，很多人为了用Builder而用Builder。真正的信号是构造参数超过四五个，而且大量参数可选、有默认值。这时候用new加setter的问题不是丑，而是容易出现半初始化对象——set到一半，别人把对象拿走了。Builder分步构建，最后一步build()，能避免这种中间态泄露。Java的Lombok @Builder就是这种思路的自动化。

2. 结构型模式盯住的是“东西拼起来之后长什么样”

2.1 结构问题比创建问题更隐蔽

创建型解决的是“对象怎么来”，结构型解决的是“对象和类怎么组成更大的结构”。很多时候对象都创建成功了，但系统用起来很别扭：两个类的接口对不上、一个对象需要动态加功能、一个树形结构需要统一处理。这些是结构层面的问题，不是创建层面的问题。

结构型模式主要通过组合和继承把已有的类组织起来，核心原则是：优先使用组合，少用继承。因为继承改变的是静态的类型关系，而组合可以在运行时拼出新的行为。比如一个对象要不要加权限校验，如果靠继承，你得住出“带权限的订单Service”“带日志的订单Service”“带权限又带日志的订单Service”一堆子类；如果靠装饰器，包一层就行。

2.2 七种结构型模式按目的排一排

需要说明的是，类模式里也有继承式适配器，但现代代码里更推荐对象适配器——通过持有一个被适配对象，重写目标接口方法，这样更灵活，不会因为多继承导致问题。比如你有个旧系统的第三方支付类OldPay，方法叫payMoney()，但你们统一接口是pay()，不要改OldPay，写一个PayAdapter实现pay()，内部转发到payMoney()，这就是适配器。

2.3 四个“包装类”模式的区别：适配器、装饰器、代理、外观

很多读者会把上面几个模式弄混，因为它们看起来都是“包一层”。我用一句话区分：

• 适配器是“接口对不上，我翻译给你听”。
• 装饰器是“功能不够，我再加点料”。
• 代理是“你不用见真人，我来把关”。
• 外观是“你只需要认识我一个，后面一堆子系统我搞定”。

适配器不改变功能，只改变接口；装饰器不改变接口，只增强功能；代理不改变接口和业务，只控制访问；外观把复杂交互简化，可能内部调用多个子系统。JDK里的Collections.unmodifiableList()就是典型的装饰器，它包装一个List，把修改方法全部拦下来：

java复制public class ReadOnlyCollection<T> implements Collection<T> {
    private final Collection<T> inner;
    public ReadOnlyCollection(Collection<T> inner) {
        this.inner = inner;
    }
    @Override
    public boolean add(T item) {
        throw new UnsupportedOperationException();
    }
    // 读方法直接转发，修改方法统一拦截
}

搞清这四个，结构型题目就不会大翻车。

3. 行为型模式才真正决定程序“动不动得起来”

3.1 类和对象都建好了，程序还是难改，问题在协作

创建型把对象造出来了，结构型把对象组合好了，但对象之间怎么发消息、谁负责处理、算法怎么替换、状态怎么流转？这些是行为型模式管的事。行为型模式是设计模式里最多的一类，共十一种，因为系统真正复杂的地方往往在行为协同，而不是类长什么样。

我经常看到初学同学画了一堆漂亮的类图，但一写交互就是一大坨if (type == 1) { ... } else if (type == 2) { ... }。这就是行为型模式要解决的问题：把容易变化的算法、请求处理链、状态流转，从业务主流程里拆出去，让每个参与者只关心自己该干的那一小段。

3.2 十一种行为型模式的分组记忆法

不按字母背，按“它们在管什么”分组：

• 算法变体：策略、模板方法。
• 请求传递：命令、责任链、观察者、中介者。
• 状态管理：状态、备忘录。
• 遍历与访问：迭代器、访问者。
• 语言规则：解释器。

这个分组的好处是，遇到实际问题先问自己“它是算法要换，还是请求要转发，还是状态要流转”，然后去对应小组里找答案。比如“支付方式要频繁新增”，这是算法变体，优先考虑策略；“订单审批流程要经过不同负责人”，这是请求传递，优先考虑责任链；“播放器根据当前状态决定能不能暂停”，这是状态管理，优先考虑状态模式。

3.3 策略模式和状态模式的区别，是面试常客

我面试别人时特别爱问策略和状态的区别，因为十个人有八个会答“这两种好像都是把行为抽出来”。其实关键在“谁决定切换”。

策略模式里，客户端主动选择策略，策略对象不具备切换下一个策略的能力：

java复制PaymentStrategy strategy = PaymentStrategyFactory.get("alipay");
order.payWith(strategy);

状态模式里，状态对象内部持有上下文引用，执行完当前业务后，自己决定变成哪个状态：

java复制state.play();
context.setState(PlayingState.getInstance());

换句话说，策略模式是外部选择算法，状态模式是内部状态驱动行为。如果你写播放器时发现一堆if (state == PLAYING) { ... } else if (state == PAUSED) { ... }，可以考虑用状态模式把每类行为放到各状态类里，这样新增状态时不用打开原来的播放器类。

3.4 观察者模式不是万能事件总线

观察者模式适合“一方的变化需要通知另一方，但两边不想互相绑定”的场景。但我在真实项目里见过把观察者当消息队列灌的，十几个observer订阅同一个事件，而且事件触发链很深，出了问题根本不知道谁在监听。观察者模式用之前一定要问：这个通知真的需要发布者完全不知道订阅者吗？如果只是两三个类同步调用，直接注入依赖比观察者好排查得多。

行为型模式的核心是“分散变化、封装行为”，但它依然要遵循简单性原则。不是什么地方都需要模式，能用参数解决的事情，不要硬上一个模式类。

4. 拿到需求怎么判别：三个问题，30秒定位模式大类

4.1 先问“变因”落在哪个环节

面对一个设计任务，不要一开始就背模式。我会先问三个问题：

• 问题出在“对象怎么来的”吗？——创建型方向。
• 问题出在“类和对象怎么组合、接口能不能对上”吗？——结构型方向。
• 问题出在“对象之间的请求怎么传、职责怎么分配、算法怎么换”吗？——行为型方向。

比如“我希望一段代码里不要再new一堆具体实现类”，这是创建问题；“我需要把第三方支付接口包装成我们自己的统一支付接口”，这是结构问题；“我要让不同会员等级走不同折扣算法”，这是行为问题。三次判断，不需要两分钟。

4.2 边界案例：容易看走眼的几个模式

说几个常见“误判”：

• 工厂 vs 策略。工厂重点在“创建哪个对象”，策略重点在“创建好之后用哪个算法”。如果你要说“根据类型返回一个对象”，那是工厂；如果你说“我手里有对象，但不知道按什么规则算”，那是策略。
• 适配器 vs 外观。适配器解决接口不兼容，外观解决多个子系统难用。适配器通常只包一个类，外观会协调多个类。
• 装饰器 vs 代理。装饰器给对象加功能，代理限制或转发访问。动态代理在外观上很像装饰器，但目的完全不一样。

这些边界记起来很顶用，笔试选择题经常考。有一次我还碰到一道场景题，说“要在调用远程方法前后打印日志”，很多人选装饰器，其实是代理。因为远程方法本身就有访问控制，装饰器更侧重给本地对象加功能，代理则适合在调用链路上插入横切逻辑。

4.3 一个需求从“new”到“模式”的推演Demo

拿最常见的“下单支付”练手：最初代码可能是直接new一个支付宝对象，然后调pay()。后来需求变化：要接微信、银行卡，还要在支付前做风控校验，支付后发通知，并且各家接口参数都不一样。可以这样推演：

• 各支付接口参数格式不同：写一个PayAdapter适配不同第三方接口，结构型。
• 支付对象怎么产生：用PaymentFactory按支付方式返回具体支付对象，创建型。
• 不同支付方式的折扣、手续费算法不同：用策略模式封装算法族，行为型。
• 支付前的风控、限购、安全校验串成链：责任链模式，行为型。
• 下单页只需要调一个facade.pay(order)：用外观模式封装订单、库存、支付等子系统，结构型。

这一套如果画成类图，就是一个很标准的设计模式大作业骨架。注意它不是一次设计出来的，而是每来一个新需求，发现一个变化点，引入一个模式。你在大作业文档里把这个过程写清楚，老师会觉得你真的理解了模式。

5. 最近的智能体设计里，也能看到这三种分类的影子

5.1 多Agent系统为什么也需要“模式”

我最近在整理多Agent系统的架构，发现所谓“多Agent设计模式”并不是无中生有，很多思路和经典设计模式高度重合。原因很简单：设计模式解决的是对象之间的创建、结构和协作问题；多Agent系统里，Agent本身也是运行时对象，同样存在“谁创建Agent”“谁组合Agent”“Agent之间怎么协作”的问题。只是换了马甲，核心逻辑并没有变。

所以别觉得设计模式过时了。相反，在智能体框架里，设计模式反而成了理解新概念的地图。群里提到的“最新的多Agent设计里主从模式”“把subagent视作另类的tool进行调用”，用经典模式一看就能拆解出好几层。

5.2 主从模式与subagent“工具化”背后的模式拼图

多Agent设计中常见的主从模式，很多人把它当成完全新的东西。但从设计模式视角看，主从模式同时吃到了结构型和行为型的红利：

• 主Agent往往被设计成统一入口，编排下属子Agent，这很像外观模式或代理模式。
• 每个subagent通过“工具协议”暴露给主Agent，其实就是用适配器统一接口。
• 主Agent根据任务类型选择调用哪个subagent，又很像策略模式或命令模式。

比如你定义了一个tool协议（name、description、parameters），然后每个Agent都包装成这个协议暴露出去：

python复制class WeatherAgent:
    name = "weather"

    def run(self, query: str) -> str:
        return f"weather result: {query}"

# 框架层把任意 Agent 包装为 Tool
class AgentTool:
    def __init__(self, agent):
        self.name = agent.name
        self.fn = agent.run

主Agent在规划时拿到的其实是“统一接口 + 一组策略”，这和我以前写支付策略的类图几乎一模一样。所以如果你已经有设计模式基础，学多Agent设计会快很多，至少不会被“工具协议”这种新名词唬住。

5.3 新场景也要记住旧原则：不要一上来就堆模式

我看到一些多Agent示例项目，十几个Agent各种角色，最终很难维护。同样的教训在经典设计模式中也存在：模式是用来封装变化点的，不是用来开演唱会的。一个简单任务用单个Agent加几个工具就能做好，就不需要硬凑主从。设计模式真正的作用是“当变化点出现时，用最小的代价把变化隔离掉”，这个思维放到Agent架构里同样适用。

6. 备考、大作业、面试：怎么把这套框架变成分数

6.1 期末复习别背定义，背“问题卡片”

如果你在准备设计模式期末考试，我建议不要按“模式列表”背。反过来做卡片，每张卡片写三行：

• 它解决什么问题？
• 不解决什么问题？
• 最小代码示意或一句口诀。

比如单例：解决唯一实例；不解决线程安全问题（要自己加锁）；口诀“构造函数私有，静态方法返回”。这样到考场上看到场景题，你先判断“这描述的问题是创建、结构还是行为”，再落到具体模式，不容易张冠李戴。

6.2 大作业选题和写法：一个案例吃透三类

很多同学的“设计模式大作业”喜欢选“超市收银系统”，然后写上“这里用了工厂，那里用了观察者”，老师一问为什么就答不上来。我的建议是：选一个你特别熟悉的小业务，比如“在线文档编辑器”：

• 文档类型不同：用工厂或原型创建文档。
• 工具栏和文档内容分离：用桥接。
• 文本、图片、表格的树形嵌套：用组合。
• 给文字加粗、加色、插入链接后还能撤销：命令加备忘录。
• 字体大小和布局不同主题：策略。

这样每个模式都有不可替代的理由，而且覆盖了创建型、结构型、行为型三类，老师挑不出“堆砌模式”的毛病。写文档时一定写上“如果没有这个模式，改动会发生在哪里”的对比，这是大作业得分关键。另外，别只盯着Java，C++的模板机制和标准库也一样能用这些模式说话，表达方式不同，但思维一致。

6.3 我这些年学模式的真实体会

最后聊点没人写在PPT上的东西。设计模式不是一次性背完就能用的，它更接近“重构经验”。我的路径是先写一堆糟糕的if/else代码，然后每次改需求都觉得痛，再去查“这种痛叫什么名字”，慢慢才对上号。模式和语言无关，Java、C++、Go都适用，只是标准库里的叫法不同。JDK的Collections就是一张活生生的模式图鉴：unmodifiableList是装饰器，asList是适配器，sort的Comparator是策略。另外，设计模式和DDD也不是替代关系，DDD偏战略层面的限界上下文和聚合设计，设计模式偏战术层面的对象协作实现。你可以先学设计模式，再去看DDD，会发现很多术语对得上。当你把模式当成“描述疼痛的语言”，而不是“考试名词清单”，设计模式才算真正学进去了。