中介者模式通过Mediator接口解耦同事类，避免直接引用导致的紧耦合；ConcreteMediator仅协调跨同事协作规则，不承担具体业务逻辑；同事类须保持完整行为能力，仅在影响他方时通知中介者；Spring中应通过构造注入和延迟初始化规避循环依赖与初始化问题。
中介者接口设计：为什么不能直接让同事类互相引用
同事类（Colleague）如果直接持有其他同事的引用，修改一个类就可能牵连多个类，测试和维护成本陡增。中介者模式的核心就是把“谁该响应谁”这个逻辑从同事类里抽出来，统一交给 Mediator 接口处理。
实操建议：
立即学习“Java免费学习笔记（深入）”；
-
Mediator接口只定义通知方法（如notify(Object sender, String event)），不暴露具体同事类型，避免循环依赖 - 同事类构造时只接收
Mediator实例，禁止在同事内部 new 其他同事或强转 mediator 为具体实现类 - 常见错误：把
ConcreteMediator的引用塞进每个同事——这等于换汤不换药，还是紧耦合
ConcreteMediator 实现：如何避免变成上帝类
中介者容易演变成包揽所有交互逻辑的巨型类，一旦业务变复杂，它就成了新瓶颈。关键不是“要不要写逻辑”，而是“逻辑归属是否清晰”。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 只在
ConcreteMediator中协调「跨同事的协作规则」，比如“按钮点击后，先校验输入框，再启用提交按钮”，而不是“校验逻辑本身” - 把校验、计算、状态转换等具体行为留在对应同事类中，用
colleague.handleEvent()委托调用 - 参数差异注意：
notify()方法传Object sender比传具体类型更灵活，但必须在实现里做instanceof判断，否则运行时报ClassCastException
同事类怎么写才不算白套模式
很多实现里同事类只剩一个 mediator.notify(this, "click")，其余全是 getter/setter——这不是解耦，是加了一层无意义转发。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 同事类应保留完整状态和行为能力，比如
TextBox自己管理文本内容、触发格式化，只在“内容变更影响其他组件”时通知中介者 - 避免在同事类中调用
mediator.getButton().setEnabled(true)这类直操作——中介者应通过事件驱动，而非暴露同事实例 - 性能影响：频繁通知+反射查找处理逻辑会拖慢响应；简单场景下，用
Map<string consumer>></string>预注册事件处理器比 if-else 更快
Spring 环境下怎么自然接入中介者
硬编码 new ConcreteMediator 和同事实例，跟 Spring 的生命周期、依赖注入就脱节了，容易出现空指针或初始化顺序问题。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 把
ConcreteMediator声明为@Component，同事类也用@Component+ 构造注入 mediator，Spring 自动完成装配 - 别在 mediator 构造器里直接调用同事方法——此时同事可能还没完成 @PostConstruct 初始化，改用
@EventListener或ApplicationRunner延迟到上下文就绪后绑定 - 常见错误：同事类用
@Autowired注入 mediator，而 mediator 又反过来注入同事，造成循环引用；正确做法是 mediator 用ObjectProvider<colleague></colleague>或延迟初始化
