中介者模式通过中心协调者将多对多依赖转为多对一星型结构，同事类仅依赖中介接口、不互相引用，交互逻辑集中于中介者内部，注册机制支持动态管理与测试替换。
中介者模式通过引入一个中心协调者，把原本分散在多个类之间的直接调用关系收束到单一中介对象上，从而把“多对多”的网状依赖转变为“多对一”的星型结构。
把直接引用变成单向依赖
在没有中介者时，A 类可能要调用 B、C、D 的方法，B 又可能反过来调用 C 和 D，形成交错依赖。使用中介者后，A、B、C、D 都只持有 Mediator 的引用，彼此不再互相持有或创建对方实例。它们只负责自身逻辑，通信统一走中介者转发。
- A.send() → 调用 mediator.notify(A, “msg”)
- mediator 接收后遍历注册的同事，过滤掉 A 自身，再调用 B.receive()、C.receive()
- B 和 C 完全不知道 A 的存在，也不需要 import A 类
交互逻辑集中到中介者内部
原来散落在各处的协作规则（比如“只有买家付款后才通知物流发货”“禁言用户不能发消息”）被抽离出来，统一写在中介者的 relay() 或 sendMessage() 方法里。同事类不再判断上下文、不决定发给谁、不处理权限校验——这些都由中介者承担。
- 同事类只需关注“我该做什么”，比如 User.send() 只管把消息传出去
- 中介者负责“谁该收到、什么时候发、要不要过滤”，比如 ChatRoom.sendMessage() 内部做身份检查、广播过滤、状态同步
- 新增规则（如加“撤回消息”功能）只需改中介者，不用动每个 User 子类
注册机制替代硬编码关联
同事对象不是在代码里 new 出其他同事，而是通过 register() 方法加入中介者管理的集合中。这个集合可以是 List、Map 或 Set，支持动态增删，也便于测试替换（比如用 MockMediator 替代真实实现）。
- 新建 ChatUser("Alice") 时自动调用 mediator.addUser(this)
- 中介者内部维护 List
users，后续所有转发都基于该集合 - 如果某用户下线，调用 mediator.removeUser(user)，其余用户完全无感
接口隔离降低感知范围
同事类只依赖抽象 Mediator 接口，不依赖具体实现；中介者也只依赖抽象 Colleague 接口，不依赖具体 User、Buyer、Logistics 等子类。双方都面向契约编程，各自演进互不影响。
- User 构造器接收 Mediator（接口），不是 ChatRoom（实现类）
- ChatRoom 实现 Mediator 接口，但内部可自由切换存储结构（ArrayList → ConcurrentHashMap）或添加日志、重试等横切逻辑
- 未来新增 PaymentService 同事类，只要实现 Colleague 接口并注册，无需修改现有 User 或 ChatRoom 代码
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
