中介者（Mediator）与命令（Command）设计模式差异及适用场景确认

中介者（Mediator）和命令（Command）都属于行为型设计模式，核心都是通过中间对象实现发送者与接收者的解耦——中介者模式的中间对象是Mediator，命令模式的中间对象是Command。二者的表层意图差异很明确：

• 命令模式：将函数调用封装为对象，借此获得面向对象的特性（比如可撤销、可队列化、可参数化等）
• 中介者模式：提取并集中处理多个对象间的复杂交互逻辑，避免对象间形成网状依赖

关于你的观察的正确性与补充 #

你的核心观察方向是对的，但可以补充一些细节让结论更全面：

1. 单向/双向交互

   • 命令模式确实是单向的：每个Command对象只负责封装“发送者→接收者”的一次调用，若要实现反向交互，确实需要新增对应的Command类。但注意，命令模式的核心并非“单向”，而是“将调用封装为对象”，单向只是这种封装带来的自然结果。
   • 中介者模式的双向交互是其核心目标之一：所有对象都只与Mediator通信，由中介者转发或处理交互请求，对象间无需直接关联，因此天然支持双向甚至多向交互。

2. 分布式vs集中式消息传递

   • 命令模式的分布式特性符合单一职责原则：每个Command只对应一个具体操作，测试时只需关注该操作的输入输出，修改时影响范围极小，可读性和稳定性都更优。但要注意，命令模式通常会搭配命令管理器/调用者（比如Invoker）来管理命令的执行、撤销等，这部分是集中的，但命令本身是分布式的。
   • 中介者模式的集中式同样符合单一职责原则：Mediator的职责就是处理所有关联对象的交互逻辑，所有对象间的复杂依赖都集中在一处，避免了对象间的直接耦合，修改交互规则时只需调整Mediator的逻辑，无需修改多个对象。但如果交互逻辑过于复杂，Mediator可能会变成“上帝类”，违背单一职责，这是需要规避的风险。

何时优先选择某一种模式 #

你的观察可以直接指导模式的选择，再结合场景补充：

• 优先选命令模式的场景：

  • 需要对操作进行封装，支持撤销、重做、队列执行、日志记录等功能时（比如编辑器的撤销操作、任务调度系统）
  • 操作本身独立，不需要多个对象间复杂交互，只需要将“请求”封装为对象传递时
  • 希望降低发送者与接收者的耦合，且每个请求对应单一职责的操作时

• 优先选中介者模式的场景：

  • 多个对象间形成复杂的网状依赖，每个对象都需要和其他多个对象交互时（比如UI组件库中，按钮、输入框、弹窗等组件的交互协调）
  • 需要集中管理对象间的交互规则，便于统一修改和维护时
  • 希望减少对象间的直接关联，降低系统整体耦合度时

关于Command Dispatcher的说明 #

你提到的“Command Dispatcher”并不是标准的命令设计模式，它更像是命令模式的一种扩展实现——通常是一个集中式的组件，负责接收命令并分发给对应的处理者，有点介于命令模式和中介者模式之间，但核心还是基于命令模式的封装思想。

内容的提问来源于stack exchange，提问作者Niek Beijloos