Java对象协作有三种方式：一是直接方法调用，依赖引用传递与访问权限；二是通过接口解耦，实现依赖抽象而非具体类；三是利用函数式接口回调，支持异步通知与轻量协作；需警惕static工具类导致的隐式协作问题。
对象通过方法调用直接协作
Java 中最常见、最直接的对象协作方式，就是在一个对象的方法里调用另一个对象的 public 方法。这依赖于引用传递：只要持有对方的引用（比如作为字段、参数或局部变量），就能发起调用。
注意点：
- 被调用方法必须是
public或具有足够访问权限（如包内可见、protected） - 调用方不能假设被调用对象处于某种特定状态——除非契约明确（比如文档或接口约定）
- 避免在构造器中调用可被重写（
non-final）的实例方法，否则可能触发子类未初始化完成时的逻辑
public class UserService {
private final EmailService emailService;
public UserService(EmailService emailService) {
this.emailService = emailService; // 依赖注入
}
public void register(User user) {
user.setStatus("ACTIVE");
emailService.sendWelcomeEmail(user.getEmail()); // 直接协作
}
}
使用接口解耦协作关系
硬编码依赖具体类会让协作僵化。用接口定义行为契约，让调用方只依赖抽象，被调用方只需实现接口——这是降低耦合的核心手段。
典型场景：
立即学习“Java免费学习笔记（深入）”；
- 多个实现类需替换（如
FileLogger和DatabaseLogger） - 单元测试时需 Mock 协作对象（用
Mockito.mock(Logger.class)） - Spring 等框架自动装配时，按类型匹配接口实现
错误示例：new DatabaseLogger() 写死在业务类中；正确做法是声明 private final Logger logger，由外部注入实现。
通过回调函数（Functional Interface）反向通知
当协作不是单向“调用-返回”，而是需要被调用方在某个时机主动通知调用方时，Java 8+ 推荐用函数式接口（如 Consumer、BiFunction）传入回调逻辑。
优势明显：
- 比传统
Listener接口更轻量，无需定义新类型 - 支持 lambda 表达式，协作逻辑内联，意图清晰
- 避免因匿名内部类导致的内存泄漏（尤其 Android 场景）
public class DataFetcher {
public void fetchData(String url, Consumer onSuccess, Runnable onError) {
// 模拟异步请求
if (url.contains("success")) {
onSuccess.accept("{\"data\": 42}");
} else {
onError.run();
}
}
}
// 使用
fetchData("https://api.example/success",
data -> System.out.println("Got: " + data),
() -> System.err.println("Failed")
);
警惕隐式协作：static 工具类与全局状态
看似无害的 static 工具方法（如 StringUtils.isEmpty()）其实是一种“无主协作”——调用方不持有协作对象引用，也不控制其生命周期。这类协作容易掩盖真实依赖，给测试和演进带来麻烦。
更危险的是静态可变状态，比如：
- 静态集合缓存（
private static Map）引发并发问题cache - 静态配置对象被多处修改，导致行为不可预测
- 日志器（
private static final Logger log = ...）虽安全，但若混入业务逻辑（如静态计数器），就破坏了单一职责
真正需要协作的对象，应该显式创建、显式传递、显式管理生命周期——哪怕只是用 @Autowired 或构造器注入，也比藏在 static 里强。
