Java对象交互本质是通过public方法调用传递消息，需确保非null、优先接口依赖、避免getter/setter破坏封装、推荐构造注入、合理使用回调与明确生命周期权责。
对象之间通过方法调用传递消息
Java 中对象交互的本质是「一个对象调用另一个对象的 public 方法」，这相当于发送一条消息。被调用方根据自身状态和逻辑做出响应，可能修改内部状态、返回结果，或触发其他对象行为。
关键点在于：方法必须是 public（或至少对调用方可见），且接收方对象不能为 null，否则会抛出 NullPointerException。
- 推荐使用「问-答」模式：比如
order.calculateTotal()询问订单总价，而不是暴露order.items让外部遍历计算 - 避免在构造函数里直接调用其他对象的业务方法（易导致初始化未完成就触发副作用）
- 若需跨模块调用，优先通过接口类型声明依赖（如
PaymentProcessor processor），而非具体实现类
用 setter / getter 实现简单协作但有风险
setter 和 getter 是最基础的协作方式，常用于配置对象或读取中间结果，但容易破坏封装性。
常见误用场景：user.getAddress().setCity("Beijing") —— 这种链式调用看似简洁，实则让外部绕过 User 对 Address 的管控权，Address 状态变更不会通知 User，后续校验或缓存可能失效。
立即学习“Java免费学习笔记（深入）”；
- 只对真正需要外部可变的属性提供
setter；多数情况下应设为final或仅提供带校验的修改方法（如changeEmail(newEmail)） -
getter返回集合时，别直接返回内部List引用，改用Collections.unmodifiableList(items)或返回新副本 - 如果属性只是临时中转，考虑用参数传递代替 getter/setter（例如把
config.getTimeout()改为方法参数int timeout）
依赖注入让协作关系更清晰可控
当一个对象需要另一个对象才能工作（如 OrderService 需要 InventoryClient），硬编码 new InventoryClient() 会导致耦合、难测试、难替换。
主流做法是把依赖作为构造参数或 setter 参数传入，由外部（如 Spring 容器或单元测试）控制实例创建时机和具体类型：
public class OrderService {
private final InventoryClient inventoryClient;
// 构造注入 —— 推荐，依赖明确、不可变
public OrderService(InventoryClient inventoryClient) {
this.inventoryClient = Objects.requireNonNull(inventoryClient);
}
public boolean isAvailable(String sku) {
return inventoryClient.checkStock(sku) > 0;
}
}
- 构造注入优于 setter 注入：能保证依赖不为空，也便于做不可变设计
- 自己手写 DI 时，注意循环依赖会直接导致栈溢出（A 构造时要 new B，B 构造时又要 new A）
- 测试时可轻松传入 mock 实现，比如
new OrderService(new MockInventoryClient())
回调与事件机制适合松耦合场景
当对象 A 不关心谁响应、也不希望等待结果（比如日志上报、异步通知），可用回调（Callback）或观察者模式解耦。
典型例子：CompletableFuture.thenAccept(result -> notifyUser(result))，这里 notifyUser 是回调，执行时机由 CompletableFuture 控制，OrderService 不持有 Notifier 引用。
- 避免在回调里做耗时操作（如数据库写入），否则阻塞主线程或线程池
- 若用
Observer或自定义事件总线，确保注册/注销配对，防止内存泄漏（尤其 Activity/Fragment 场景） - Spring 的
@EventListener是声明式回调，底层仍是发布-订阅，但要注意事件默认同步执行
ConnectionPool 对象被多个 service 共享，关闭时机必须统一协调，不能各自调用 close()。这种隐含契约，光靠代码很难表达清楚，得靠文档或接口命名（如 SharedConnectionPool）来提示。 
