Java对象协作有三种方式：一是直接方法调用，依赖引用传递与访问权限；二是通过接口解耦，实现依赖抽象而非具体类；三是利用函数式接口回调，支持异步通知与轻量协作；需警惕static工具类导致的隐式协作问题。
对象通过方法调用直接协作
Java 中最常见、最直接的对象协作方式，就是在一个对象的方法里调用另一个对象的
方法。这依赖于引用传递：只要持有对方的引用（比如作为字段、参数或局部变量），就能发起调用。
注意点：
被调用方法必须是
或具有足够访问权限（如包内可见、
）
调用方不能假设被调用对象处于某种特定状态——除非契约明确（比如文档或接口约定）
避免在构造器中调用可被重写（
）的实例方法，否则可能触发子类未初始化完成时的逻辑
使用接口解耦协作关系
硬编码依赖具体类会让协作僵化。用接口定义行为契约，让调用方只依赖抽象，被调用方只需实现接口——这是降低耦合的核心手段。
典型场景：
立即学习
“
Java免费学习笔记（深入）
”；
多个实现类需替换（如
和
）
单元测试时需 Mock 协作对象（用
）
Spring 等框架自动装配时，按类型匹配接口实现
错误示例：
写死在业务类中；正确做法是声明
，由外部注入实现。
Eclipse导入Android或其他的JAVA项目的正确方法 WORD版
本文档主要讲述的是Eclipse导入Android或其他的JAVA项目的正确方法；希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
下载
通过回调函数（Functional Interface）反向通知
当协作不是单向“调用-返回”，而是需要被调用方在某个时机主动通知调用方时，Java 8+ 推荐用函数式接口（如
、
）传入回调逻辑。
优势明显：
比传统
接口更轻量，无需定义新类型
支持 lambda 表达式，协作逻辑内联，意图清晰
避免因匿名内部类导致的内存泄漏（尤其 Android 场景）
警惕隐式协作：static 工具类与全局状态
看似无害的
工具方法（如
）其实是一种“无主协作”——调用方不持有协作对象引用，也不控制其生命周期。这类协作容易掩盖真实依赖，给测试和演进带来麻烦。
更危险的是静态可变状态，比如：
静态集合缓存（
）引发并发问题
静态配置对象被多处修改，导致行为不可预测
日志器（
）虽安全，但若混入业务逻辑（如静态计数器），就破坏了单一职责
真正需要协作的对象，应该显式创建、显式传递、显式管理生命周期——哪怕只是用
或构造器注入，也比藏在
里强。
publicpublicprotectednon-finalpublic 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()); // 直接协作
}
}FileLoggerDatabaseLoggerMockito.mock(Logger.class)new DatabaseLogger()private final Logger loggerConsumerBiFunctionListenerpublic 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")
); staticStringUtils.isEmpty()private static Map cache private static final Logger log = ...@Autowiredstatic