Java中对象“说话”本质是通过接口定义消息协议实现松耦合协作，而非简单方法调用；关键在于依赖抽象、运行时注入、明确契约（如null/异常/线程安全约定），避免Observer等伪解耦。
Java里对象怎么“说话”：消息传递不是调用方法那么简单
Java没有原生的“消息传递”机制——所谓协作式设计里的“发送消息”，实际就是方法调用，但关键在**谁调用、何时调用、依赖是否显式暴露**。很多人误以为加个 notify() 或用 Observer 就算消息传递，其实那只是特定场景的实现，不是设计本质。
真正的协作式设计，核心是让对象只关心“能接收什么消息”，不关心“对方是谁、怎么实现”。这靠接口和松耦合达成，不是靠语法糖。
怎么写出有消息感的对象：用接口定义“协议”，而非直接 new 实例
常见错误是 A 类直接 new B()，然后调用 b.doSomething()——这叫强依赖，不是协作。A 无法替换 B 的实现，也无法在运行时切换行为。
- 把
B的能力抽象成接口，比如PaymentProcessor - A 类只持有
PaymentProcessor引用，不关心具体是AlipayProcessor还是WechatProcessor - 构造或方法参数注入实现类，而不是自己创建——这就是“消息接收方可插拔”的基础
示例：
public class OrderService {
private final PaymentProcessor processor; // ← 只认“协议”
public OrderService(PaymentProcessor processor) {
this.processor = processor; // ← 消息接收方由外部决定
}
public void checkout() {
processor.process(); // ← 这才是“发消息”：我不知你怎么做，只知你能做
}
}
为什么不用 Observer / EventListener 就不是协作式设计？
用 java.util.Observer 或自定义事件总线，容易陷入“伪解耦”：监听器仍需注册到具体被观察对象，且事件类型常是具体类（如 OrderCreatedEvent），导致上下游隐式绑定。
立即学习“Java免费学习笔记（深入）”；
真正轻量的消息协作，推荐更克制的做法：
- 优先用回调函数（
Consumer<result></result>、BiFunction<...></...>）传入行为，避免引入事件生命周期管理 - 若必须异步通知，用
CompletableFuture链式传递结果，比手动维护 listener 列表更清晰 - 警惕 Spring 的
@EventListener：它让监听逻辑散落在各处，调用链路不可见，调试时容易丢失“谁在响应哪条消息”
容易被忽略的边界：null 值、异常、线程安全不是“消息协议”的一部分
协作式设计默认假设消息接收方能处理输入。但 Java 不强制校验 null、不声明受检异常、也不保证方法线程安全——这些都得靠协作双方私下约定，否则“发消息”就变成“扔炸弹”。
实操建议：
- 接口方法文档里明确写清
@param是否允许null，比如process(@NonNull String orderId) - 用
Optional<t></t>表达“可能无响应”，比返回null更符合消息语义 - 如果消息需跨线程（如 UI 更新），接收方必须自行处理同步，发送方不应假设
SwingUtilities.invokeLater已包裹
消息能发出去，不等于对方收到了；对方收到了，也不等于它能正确处理。协议之外的细节，最容易在联调时突然冒出来。
