眠子子子1. 别小看"其他模式"，它们才是代码里的隐形主角
聊到行为型设计模式，大多数人第一反应是策略、模板方法、观察者这三个"大件"，原因也很直白——这仨在面试里出镜率高，在日常业务代码里的应用密度也高。但真正等你啃完《设计模式》那本书，或者把一个大型项目从零维护到上线，你会发现那些被归进"其他模式"的家伙——状态、命令、责任链、中介者、备忘录、访问者、解释器——才是让系统活下来的骨架。
这篇文章主要想聊聊这8个"行为型模式第二梯队"。我不会给你念教科书式的定义，而是把它们放在真实开发场景里：订单状态机怎么写才不烂尾？审批流怎么设计才能灵活增删节点？编辑器撤销功能背后的快照机制到底是什么？为什么有些人说访问者模式"反直觉"，但编译器里处处是它？另外，我还会把这些模式和最近几年特别火的多Agent系统架构联系起来聊一聊——你可能会惊讶地发现，所谓"主从模式""子Agent作为工具被调用"的设计思路，早在几十年前就被这8个模式预演了一遍。
适合谁看？两类人：一是正在为设计模式期末考试或大作业发愁的学生，看完能直接从"背概念"进阶到"讲得出场景和取舍"；二是工作了两三年、写了很多CRUD但觉得代码味道不对的开发者，尤其是做Java和C++的，这篇文章能把"味道不对"背后的模式原因帮你撬开。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 状态模式与命令模式：把"行为"变成对象的两种底层思路
2.1 状态模式：不是消灭if-else，而是让状态迁移自己管理自己
先聊一个我在实际项目里反复踩坑的场景：订单状态流转。很多初版代码会写成这样：
java复制if (order.getStatus() == CREATED && event == PAY) {
order.setStatus(PAID);
} else if (order.getStatus() == PAID && event == SHIP) {
order.setStatus(SHIPPED);
}
看起来人畜无害，但一旦状态增加到七八个、事件变成十几个、中间还要穿插各种校验和回调，这段代码就会变成一座屎山。最痛苦的地方在于：每一个状态迁移都要重新看一遍前面所有分支，改一个状态就得把整个if-else链翻一遍。这其实就是状态模式要解决的典型问题——把"状态"本身变成对象，让状态自己决定它能响应什么事件、迁移到哪个下一个状态。
状态模式的核心结构不复杂：一个State接口，若干具体状态类，一个持有当前状态引用的上下文对象。它的妙处在于"迁移逻辑归属权"发生了变化。原来所有迁移逻辑集中在一个巨大的方法里，现在每个状态类只关心自己负责的那几件事。新增一个状态不再需要动其他地方，只要实现接口、注册迁移关系即可。
举个例子，我用C++写一个简单的TCP连接状态机片段：
cpp复制class Connection : public enable_shared_from_this<Connection> {
unique_ptr<State> state_;
public:
void setState(unique_ptr<State> state) { state_ = move(state); }
void open() { state_->open(shared_from_this()); }
void close() { state_->close(shared_from_this()); }
};
class State {
public:
virtual ~State() = default;
virtual void open(shared_ptr<Connection> conn) = 0;
virtual void close(shared_ptr<Connection> conn) = 0;
};
class ListeningState : public State {
public:
void open(shared_ptr<Connection> conn) override {
// 进行握手、建立连接等操作
conn->setState(make_unique<EstablishedState>());
}
// ...
};
这里有个特别容易忽略的细节：状态对象是无状态的，还是带上下文的？ 如果状态对象本身不存字段，多个上下文可以共享同一个状态实例；如果它依赖上下文数据，就必须每次创建或持有上下文引用。我见过不少设计模式教程在这上面含糊其辞，导致新手在并发场景下写出数据串了的问题。我的经验是：优先做无状态状态对象，把需要变化的数据全部放到上下文里，传参进去。这样既省内存，也好做并发控制。
还有一个高频问题：状态模式和策略模式有什么区别？这俩结构几乎一模一样，但语义完全不同。策略模式是"外部选择一个算法塞给你"，主动权在调用方；状态模式是"状态自己决定下一步去哪个状态"，主动权在内部。一个是被动的，一个是主动的。
2.2 命令模式：把请求打包成可排队、可撤销、可重放的对象
命令模式的设计初衷其实特别朴素：方法调用没办法被存储、排队、撤销、重放，但对象可以。那好，我们把一个操作封装成对象，就叫命令。
命令模式有四个参与角色：Command接口、具体命令类、接收者（真正干活的业务对象）、调用者（发起命令的入口）。你可能觉得这层封装有点多余，把逻辑写在Controller里不香吗？但等到你需要做操作历史、宏命令、任务队列这些功能时，就知道"拆出来"的好处了。
以编辑器里的撤销功能为例。每次操作（输入文字、删除文字、加粗）都生成一个命令对象，对象里存了执行和撤销两个方法，以及执行这个命令所需要的最小上下文。用户点一次撤销，系统从历史栈里弹出最后一个命令，调用它的undo()就行。这比记录"操作前的快照"省内存得多——记住，备忘录模式是整页快照，命令模式是增量逆操作，两者适用场景不一样。
命令模式在Java里还有一个非常有意思的延伸——由于Java支持匿名内部类和Lambda，很多原本要用命令模式的场景被函数式接口替代了。比如：
java复制button.addActionListener(e -> saveFile());
这个Lambda本质就是一个命令对象。所以很多时候不是命令模式无用了，而是语言特性把它"内化"了。这提醒我们一件事：设计模式是思想，Java和C++的实现方式可以不一样，别死板地非要建一堆类。
我在C++项目里用命令模式处理过批量任务队列，感受最深的是：命令对象要尽量轻量，不要在命令里放业务上下文的大引用。曾经我把整个交易对象塞进命令，结果队列里积压几千个命令时内存飙得吓人。正确的做法是只放业务对象的ID，命令执行时再通过ID去查数据。
3. 责任链与中介者：从"谁能处理"到"谁来处理"的控制权转移
3.1 责任链模式：让每个处理器只认自己关心的那件事
责任链模式在实际业务中出现频率极高，但很多人意识不到自己写的是责任链。日志框架里的级别过滤（DEBUG->INFO->WARN->ERROR）、Servlet里的Filter链、Spring MVC里的拦截器，本质都是责任链的变形。
责任链的构建极其简单：每个处理器持有下一个处理器的引用，请求从链头进入，每个处理器决定自己处理还是传给下一个。真正难的是链的组装和断点处理。
我见过一个真实案例：某订单审批流程，最初只有"部门经理 -> 总监 -> CEO"三级。用代码写死倒也简单。结果业务部门提出要加"金额大于10万必须走财务复核""特殊客户跳过经理层"等等需求，写死的if-else就崩了。改成责任链之后，每个审批节点是一个独立的处理器，链条顺序和节点增删全部通过配置来组装，业务只需要变更配置就能调整流程，完全不用改代码。
但责任链有个暗坑：谁来保证请求一定有处理器能处理？ 如果链尾没有兜底逻辑，请求就会静默丢失，这种Bug非常难排查，因为不是报错，而是"什么都没发生"。好的实践是在链尾加一个EndHandler，要么抛异常，要么至少记一条WARN日志，保证任何进入链的请求都有明确的归宿。
责任链和装饰器模式在结构上长得很像，都是"对象持有下一个对象的引用"，但语义方向完全相反：装饰器是"每个对象都干活，层层增强"，责任链是"每个对象只决定自己干不干，不干就传给下一个"。这俩区分清楚了，理解设计模式的思路就通了一半。
3.2 中介者模式：从"人人互相加引用"到"所有通信都过一个人"
中介者模式是针对"对象间多对多联动"设计的。最典型的例子是聊天室：不引入中介者，每个用户都要持有其他所有用户的引用，彼此直接发消息；引入中介者之后，每个用户只持有中介者的引用，消息发给中介者，由中介者决定转发给谁。
MVC架构里的Controller就是最典型的中介者。Model和View之间不直接通信，一切交互经过Controller转发。这样做的好处是对象间的依赖从"网状的"变成了"星状的"，耦合度大幅下降。代码里比聊天室更常见的场景是UI组件联动：下拉框变了，表格要刷新，按钮要置灰，状态栏要更新。如果这些组件各自持有对方的引用，那就是一个蜘蛛网；引入一个"中介者"（通常叫界面协调器），所有联动逻辑都收拢到一处，代码立刻清爽。
中介者模式在实践中最大的风险是"上帝对象"倾向——所有逻辑都汇入中介者，中介者本身变得臃肿。我自己的做法是：中介者只做"转发和编排"，不做"业务计算"，具体的业务逻辑还是放在各自的领域对象里。同时在必要时把中介者拆成多个小中介者，比如一个页面有订单区和客户区，就让订单区有自己的小中介者，客户区有小中介者，页面级中介者只负责它们之间的通信。这其实和微服务里的网关拆分思路异曲同工。
3.3 责任链与中介者怎么选
这两个模式经常会让人纠结：同样是解决"多个对象要协作"的问题，用哪个？我的判断标准很简单：如果协作是有方向的、链式的（从A到B到C），选责任链；如果是无规则的网状交互（A变了B、C、D都要响应），选中介者。 以及，责任链适用于"请求本身只有一个最优处理者"的场景，中介者适用于"一个变化需要触发多方联动"的场景。理解这个区别之后，很多架构选型就顺理成章了。
4. 备忘录、访问者、解释器：三个低频但不可替代的"冷门三兄弟"
4.1 备忘录模式：撤销功能的"后悔药"，但别让快照撑爆内存
备忘录模式要表达的奥义是"在不破坏封装的前提下，捕获并外部化一个对象的内部状态"。说人话就是：我给对象拍了个快照，需要的时候能恢复回去。
它最直白的应用就是编辑器的Ctrl+Z撤销、游戏里的存档/读档、数据库的事务回滚。通常设计里会出现一个Originator（需要被保存状态的对象）、一个Memento（快照对象）、一个Caretaker（保管快照的负责人）。
Java里最标准的实现方式是使用序列化或者深拷贝来生成快照。但有个实际问题：大对象频繁拍快照，内存会爆炸。 我做过一个带撤销功能的数据表格组件，表格每编辑一格就生成一个全量快照，结果用户连续操作几十次之后内存直接飙升。后来我改成了两个优化方向：
- 增量快照：只保存"变化的部分"，恢复时按顺序叠加
- 快照压缩/降采样：历史超过N条就合并旧快照（比如把最早的10条合并成1条中间态）
这两个策略业务耦合度低，可以做成通用组件。另外，备忘录里不要保存外部对象的引用，一定要保存值，否则你以为恢复了状态，结果引用的对象已经被别人改掉了。
4.2 访问者模式：双分派的艺术，以及它的代价
访问者模式大概是设计模式里最"反直觉"的一个，很多人第一次看都懵：为什么要把操作从对象里拿出来？它不是用来简化代码的，恰恰相反，它是为了同时管理"一组结构稳定的对象"和"一堆不断变化的新操作"。
经典的场景是编译器遍历语法树。语法树的节点类型是相对稳定的（表达式、声明、语句这些就那些），但你要对树做的操作非常多：类型检查、代码生成、优化、打印AST、统计行数。如果每个操作都塞进节点类里，节点类会被活活撑爆，而且违背开闭原则。访问者模式的做法是：节点类只实现一个accept(Visitor)方法，在方法里调用visitor.visit(this)，把控制权交给外部访问者。
这里面有个"双分派"机制：第一次分派是运行时动态确定"我具体是哪个节点类型"（因为在Java/C++里this的静态类型是基类，动态类型才是具体的子类），第二次分派是调用visitor.visit(具体节点类型)，由具体节点类型决定调用访问者里的哪个重载方法。这个机制让"在已有类结构上增加新操作"变成了"只需新增一个Visitor实现类"，完全不用改动被访问的类。
代价也很明显：新增节点类型时，所有Visitor实现类都要跟着改，否则编译都过不去。 如果你的对象结构本身也在快速变化，访问者模式就是灾难。我的经验是：节点结构稳定期用访问者放大收益，节点还在频繁增删的时候慎用。Java里javax.lang.model.element.ElementVisitor、Spring里一些组件扫描的MetadataVisitor都是它的实践案例。
4.3 解释器模式：不是让你写解释器，是让你别用正则硬刚
说到解释器模式，很多人第一反应是"这不就是写编译器吗，工作里用不上"。但其实，但凡你要解析一个自定义格式的字符串——比如模板引擎里的{{name}}、路由配置里的/users/{id}/orders/*、规则引擎里的if score > 60 then pass——你就在写一个微型的解释器。
解释器模式的经典4件套：AbstractExpression（抽象表达式）、TerminalExpression（终结符表达式，即叶子节点）、NonterminalExpression（非终结符表达式，即组合节点）、Context（上下文，存放解析过程中的中间信息）。它的数学本质是：用组合模式组织AST，递归求值。
但这里我要教给你一个真实世界的判断标准：太复杂的语法别用解释器模式去手撸，太简单的语法又没必要用。 怎么判断？如果语法不到20条规则，直接用递归下降或者正则就能搞定；如果语法有上百条规则（比如一门真正的语言），解释器模式的结构会变得极其笨重，应当引入parser generator工具（比如ANTLR）。中间地带才是解释器模式的用武之地——比如一个公司内部报表的自定义筛选表达式。
我参与过的一个项目里，就有一个需要支持"按地区+时间+渠道+金额区间"组合筛选的报表系统，用户希望用文本配置。最开始用了正则硬拆，结果组合一多就稀碎；后来重构成解释器模式，把表达式拆成AndExpr、OrExpr、ConditionExpr三种类型，解析和求值都清晰了，配置也变成了一等公民。
4.4 三个冷门模式的共同特征
备忘录、访问者、解释器这三个模式有个共同点：它们都不是为了"写起来爽"，而是为了"在特定复杂场景下保证结构稳定"。 很多教科书把它们讲得云山雾罩，是因为没有嵌入到真实场景里。你在日常业务代码里可能十天半个月碰不到它们一次，但一旦碰到了，你会发现没有它们，代码就是硬扛过来的。这也解释了为什么它们经常成为设计模式期末考试和大作业的选题——它们比策略、模板这类"一眼懂"的模式更能检验理解深度。
5. 当"其他模式"遇上多Agent系统：主从架构里藏着的模式密码
5.1 为什么说"子Agent本质上是另一种tool调用"
最近多Agent系统非常火，各种架构范式层出不穷。里面有个很有意思的观点：在主从模式（Supervisor/Worker pattern）中，主Agent把子Agent当成一种"另类的tool"来调用。
这话初听有点狂，细想很有道理。在传统Agent架构里，tool是一个函数或API，有明确的入参和出参，Agent决定何时调用它；在主从模式里，子Agent也是一个可调用的单元——主Agent下发任务给它，它返回结果，只不过这个"tool"内部不是一个函数，而是一个带着模型、上下文、记忆、子任务的独立推理单元。
那这和设计模式有什么关系？关系太大了。子Agent的注册与发现，本质是一个责任链模式：主Agent维护一个子Agent列表，按某个顺序把任务往下传，直到某个子Agent声明"这个我能搞定"；子Agent的调度策略，又很接近策略模式：根据任务类型动态选择不同的子Agent作为算法策略；维护多个子Agent状态并协作，则需要中介者模式的思维——主Agent就是协调者，不让子Agent之间互相乱引用。
5.2 主从架构中的模式映射
我梳理了一下，主从模式里的经典问题几乎都能在行为型模式里找到对应解法：
- 任务如何分发？ 责任链：依次尝试，直到有Agent能处理；或者中介者：由主Agent统一路由。
- 如何让Agent具备记忆和撤销能力？ 备忘录：对Agent的上下文状态做快照，回溯时恢复。
- 如何组合多个Agent的处理逻辑？ 命令模式：每个Agent的处理动作封装成一个命令，可以排序、重试、回滚。
这意味着什么？意味着你如果只是把"状态模式""责任链模式""命令模式"背得滚瓜烂熟但在实际工作里用不上，那么在多Agent系统设计时你真的可能会绕远路——因为你在自己造轮子。反过来，如果你吃透了这些"其他模式"，你会发现自己在设计Agent协作编排时，脑子里有非常清晰的模式语言可以调用，而不是只有"让它俩互相发消息"这一个朴素方案。
当然，多Agent系统比传统设计模式讨论的场景要复杂得多，它还有模型幻觉、动态规划、上下文窗口限制等新问题，不能简单地把23种设计模式直接套进去。但从"调用者/被调用者如何协作"这个抽象视角看，设计模式提供的词汇表依然有效。这也是我写这一章的用意：别把设计模式当成过时的老古董，它们的思想是常青的，只是载体不断换新。
6. 从Java到C++：行为型"其他模式"的语言实现差异与选型心法
6.1 Java里那些"消失了"的模式
Java语言本身的发展，已经让部分设计模式的形态发生了改变。最典型的是命令模式和策略模式——Lambda表达式普及之后，很多在Java 8之前需要定义一个匿名内部类的小场景，现在一个Lambda就解决了。你需要做的只是把一个函数式接口挂在合适的位置。
但状态模式和访问者模式在Java里依然是"重结构"的存在，原因在于Java的状态判断没有强大到可以摆脱类结构。另一个值得提的是Java的反射机制，它让访问者模式可以产生一些变体：通过反射动态分发访问方法，而不是在每个节点类里写死accept。不过这种"黑魔法"代码可读性极差，我宁愿多写几个accept，也不想让后维护的兄弟对着反射代码掉头发。
6.2 C++里那些"反人类"的模式
C++实现行为型模式的时候有几个特有难点。一是虚函数有运行时开销，状态模式如果状态切换极其频繁、方法调用量巨大，需要评估性能影响；二是C++没有GC，命令模式、责任链模式里的对象生命周期管理是个难题，智能指针用不好就是一个野指针大礼包；三是模板和元编程的引入让很多模式有了"零运行时开销"的替代方案，但代码复杂度直线上升。
以访问者模式为例，在C++里实现它有个著名的"双重分派"坑——因为C++的重载决议发生在编译期，而虚函数是运行时，两个维度叠加容易让人误判。除非必要，C++项目里我建议优先考虑std::variant加std::visit来替代部分访问者场景，静态分发，可读性好，类型安全也能保证；只有在对象层次结构必须是开放扩展时，才考虑传统访问者。
责任链模式在C++里的实现有一个很实用的姿势：用std::function作为处理器类型。
cpp复制using Handler = std::function<optional<Response>(Request)>;
class Chain {
vector<Handler> handlers_;
public:
Chain& add(Handler h) { handlers_.push_back(move(h)); return *this; }
optional<Response> handle(Request req) {
for (auto& h : handlers_) {
if (auto res = h(req)) return res;
}
return nullopt;
}
};
这样既保留了责任链的灵活性，又省掉了抽象基类和一堆子类，代码量少到令人发指。你看，这就是"模式思想+语言特性"的化学反应。
6.3 设计模式选型心法：先看变化方向，再选模式
我做设计模式选型时，最重要的一个原则是：看变化的维度，而不是看结构的相似性。 计划赶不上变化，代码也一样。每个模式都是为了一种特定的变化而生的。
- 状态变化频繁？需要新增状态或迁移规则？选状态模式。
- 操作需要排队、撤销、重放、事务化？选命令模式。
- 请求的处理者不固定、可以动态增删？选责任链模式。
- 多个对象之间有复杂的互相通知、联动？选中介者模式。
- 需要恢复历史状态、实现回滚？选备忘录模式。
- 对象结构稳定，操作经常新增？选访问者模式。
- 要解析并求值一门小型语言？选解释器模式。
切记一点：模式是用来辅助设计的，不是用来炫技的。如果一个简单的switch-case能解决问题，就不要强行上状态模式；如果lambda+if就能完成动态调用，就没必要构造策略模式那一堆类。设计模式的核心价值不是让你写出更"漂亮"的代码，而是让你的代码在需求变化来临时，改起来更省力。
7. "其他模式"不是冷门，是你还没遇到对的场景
回想我从刚入行到现在，对行为型"其他模式"的态度经历了三个转变：第一阶段是考试视角，觉得它们不如策略、模板重要；第二阶段是重构视角，在维护老代码时发现那些"一坨坨的if-else"其实就是被省略掉的状态模式和责任链；第三阶段是架构视角，在设计分布式任务编排、Agent协作这些新型系统时，发现这些古老模式的思想意外地贴合。
所以在最后，我想给出一份很私人的经验清单，不一定对所有人适用，但都是我实际踩过坑之后总结出来的：
- 状态模式是降低状态机复杂度的利器，但前提是状态之间确实存在明确的迁移关系。如果状态之间是"平等切换"，没有严格规则，用状态模式反而画蛇添足。
- 命令模式无论在新旧系统里都有用武之地，特别是任务队列、批量操作、回滚这些场景。用Lambda简化实现是趋势，但别丢掉"命令即可记录"这个灵魂。
- 责任链的链尾兜底是必须的，这个习惯能救你无数次debug时间。
- 中介者模式的成败在于职责边界，只做协调者，不做业务实现者。
- 备忘录别滥用，考虑增量快照和快照压缩方案，否则内存会教你做人。
- 访问者模式别乱用，对象层级稳定是前提，否则每加一个节点类型都要改一堆Visitor，哭都来不及。
- 解释器模式的重点不是"解析"本身，而是"语法设计"。语法设计得不好，解析器写得再漂亮也救不了。
这些模式没有一个是"冷门"，它们只是需要待在合适的场景里才能发光。保持对模式语言的理解，比记住23个模式的UML图重要得多。希望这篇梳理能帮你在考试、大作业或者真实项目里，少一点迷茫，多一点游刃有余。