Java对象协作核心是依赖关系明确化，即通过接口、方法参数、返回值和事件等契约式约定交互，优先使用接口定义行为并构造函数注入依赖，避免硬编码new、静态工具类调用及直接访问私有成员。
Java中对象协作的核心是“依赖关系明确化”
Java里对象之间不是靠“知道对方全部细节”来协作的，而是通过接口、方法参数、返回值和事件等契约式约定完成交互。强行让一个类直接访问另一个类的私有字段或内部逻辑，协作就会变得脆弱且难以测试。
关键判断：如果两个对象需要协作，优先考虑是否能用 interface 定义行为契约，再通过构造函数或 setter 注入依赖，而不是在类内部 new 另一个具体类。
用构造函数注入替代 new 关键字硬编码
硬编码 new UserService() 会让 OrderProcessor 和 UserService 紧耦合，无法替换实现（比如换成 MockUserService），也无法做单元测试。
正确做法是把依赖作为参数传入：
立即学习“Java免费学习笔记（深入）”；
public class OrderProcessor {
private final UserService userService;
public OrderProcessor(UserService userService) {
this.userService = userService;
}
public void process(Order order) {
User user = userService.findById(order.getUserId());
// ...
}
}
-
UserService应该是接口，而非具体类，这样可轻松切换为MockUserService或DbUserService - 构造函数参数加
final能防止运行时被意外替换，强化协作边界 - 避免无参构造 + setter 注入，除非框架强制（如 Spring 的 @Autowired），否则易导致对象处于不完整状态
回调与观察者模式解决“被动通知”场景
当 A 对象做完某事，需要通知 B 做后续动作（比如支付成功后发短信），但又不想让 A 直接持有 B 的引用——这时不能用“调用 B 的方法”，而要用“B 告诉 A 自己关心什么”。
最轻量的方式是传一个 Runnable 或自定义函数式接口：
public class PaymentService {
public void pay(String orderId, Runnable onSuccess) {
// 执行支付逻辑
if (success) {
onSuccess.run(); // 不关心谁实现，只执行契约
}
}
}
- 比完整观察者模式更简单，适合一对一、临时性协作
- 若需一对多或可取消订阅，才升级为
java.util.Observer（已弃用）或自定义EventBus/Subject - 注意回调中不要隐式捕获外部可变状态，否则引发并发问题
避免静态工具类破坏协作可测性
像 StringUtils.isEmpty() 这类纯函数没问题，但若写一个 NotificationUtil.sendSms()，并在多个业务类中直接调用，就等于把协作逻辑“藏进静态方法里”，导致无法在测试中拦截或模拟发送行为。
- 把工具行为封装成接口（如
SmsSender），通过依赖注入传入 - 静态方法一旦涉及 I/O、时间、随机数、系统属性等，就会让协作链路不可控
- Spring 中可用
@Bean声明单例SmsSender，既复用又可被@MockBean替换
真正难的不是写几个交互方法，而是每次新增协作点时，都得问一句：这个依赖是我必须知道它的具体类型，还是只需要它承诺做一件事？答案往往指向接口和注入——而不是继承、静态调用或包级可见字段。
