Java回调首选接口而非抽象类，因其轻量、契约明确、支持多实现及Lambda适配；设计时应命名清晰、方法粒度合理、参数精简、善用泛型；抽象类仅在需共享状态和公共逻辑且放弃Lambda时适用。
Java 中设计回调函数接口，核心是用接口，而不是抽象类——这是由回调机制的本质决定的：它需要一种轻量、契约明确、支持多实现、且能被匿名类或 Lambda 灵活适配的声明方式。
为什么首选接口而非抽象类
回调的本质是“定义行为契约，延迟由调用方提供具体实现”。接口天然契合这一需求：
- 接口方法默认 public abstract，无需强制实现无关逻辑，语义干净；
- 一个类可实现多个回调接口（如同时处理成功、失败、进度），抽象类不支持多继承；
- Lambda 表达式和方法引用只能用于函数式接口（@FunctionalInterface），抽象类无法被 Lambda 直接实例化；
- 回调通常只关心“做什么”，不关心“怎么做”或“共享状态”，无需抽象类的字段或构造逻辑。
如何设计一个实用的回调接口
关键不是堆砌功能，而是紧扣使用场景，保持简单、意图清晰、扩展友好：
-
命名体现用途：如
DownloadCallback、OnDataLoadedListener、CompletionHandler<T>，避免泛泛叫Callback； -
方法粒度合理：单方法接口优先（便于 Lambda），例如
void onSuccess(Result result)；若需多状态，可用多个方法（如onSuccess()/onError()/onProgress()），但建议拆分为独立接口或用泛型统一； - 参数设计讲逻辑：传必要上下文，比如结果对象、错误异常、原始输入、执行耗时等；避免传大对象或上下文容器（易引发内存泄漏或耦合）；
-
考虑泛型增强复用性：例如
interface ResultCallback<T> { void onResult(T data); }，让不同业务共用同一回调结构。
抽象类在回调中极少使用，但有特定适用场景
抽象类不是不能用，只是它偏离了回调的轻量契约本质。仅当满足以下全部条件时才考虑：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 回调逻辑存在大量公共基础行为（如日志记录、线程切换、重试封装）；
- 需要强制子类共享某些状态字段（如计数器、缓存 map）；
- 你明确放弃 Lambda 支持，并接受单继承限制。
例如：abstract class SafeNetworkCallback<T> implements ResultCallback<T> 可封装主线程回调逻辑，子类只需重写 onResult() 和 onError()，但这种“带壳回调”本质已是模板方法模式，已超出纯回调范畴。
真实项目中的典型写法
现代 Java（8+）推荐组合使用：
- 单方法函数式接口 + Lambda：
public interface Action { void run(); }<br>executeAsync(() -> System.out.println("done")); - 带泛型与错误处理的接口：
public interface ApiResponseCallback<T> { void onSuccess(T data); void onFailure(Exception e); } - Android 风格监听器（多方法，但命名规范、职责单一）：
public interface OnItemClickListener { void onItemClick(View v, int position); }
