抽象类适配器的核心是卸载接口全实现压力，让子类仅重写关心的方法，其余由抽象适配器空实现或提供默认逻辑；它必须abstract、implements接口、不实例化，适用于方法较多且子类只需部分功能的场景。
用抽象类做中间适配器，核心是把“必须全实现”的接口压力卸掉——让子类只写真正需要的方法，其余方法在抽象适配器里空实现或提供默认逻辑。
为什么非得用抽象类当适配器
Java 接口一旦被实现类 implements，就必须重写所有抽象方法。若接口有 10 个方法，而你只关心其中 2 个（比如 start() 和 stop()），硬写其余 8 个空方法既冗余又易出错。抽象类作为中间层，能一次性把接口所有方法“兜底”，子类只需继承它、覆盖自己关心的部分即可。
关键点：
- 适配器类必须声明为 abstract，否则无法编译（因含未实现的抽象方法）
- 适配器类用 implements 接口，不是 extends（接口不能被继承，只能被实现）
- 适配器本身不对外实例化，只供子类继承，所以构造方法可私有或包级，无需 public
标准三步写法（以 AudioDevice 接口为例）
假设有个老旧接口定义了大量音视频控制方法：
interface AudioDevice {
void play();
void pause();
void stop();
void setVolume(int v);
void setBalance(float b);
void enableEqualizer();
void disableEqualizer();
void record();
void exportLog();
void calibrate();
}
你只想支持播放和音量调节，那就建一个适配器：
abstract class AudioDeviceAdapter implements AudioDevice {
public void play() {}
public void pause() {}
public void stop() {}
public void setVolume(int v) {}
public void setBalance(float b) {}
public void enableEqualizer() {}
public void disableEqualizer() {}
public void record() {}
public void exportLog() {}
public void calibrate() {}
}
然后你的具体类直接继承它：
class SimplePlayer extends AudioDeviceAdapter {
@Override
public void play() { System.out.println("▶ 播放音频"); }
@Override
public void setVolume(int v) { System.out.println("? 音量设为：" + v); }
}
进阶技巧：给常用方法加默认实现
空方法虽安全，但有些逻辑其实可以复用。比如 stop() 往往就是暂停+重置位置，适配器里可预埋通用行为：
- 把 setVolume() 默认限制在 0–100 范围内，避免子类重复校验
- 让 pause() 自动调用 stop() 后再保存当前进度（如果子类有状态字段）
- 把日志、异常包装等横切逻辑统一放在适配器方法体中，子类专注业务
这样既保持轻量，又提升健壮性——适配器不是摆设，是可演化的契约基座。
注意边界：什么情况不适合用这种适配器
不是所有接口都适合套这个模式：
- 接口方法少于 4 个，直接实现更清晰
- 接口会高频迭代（新增/删减方法），每次都要同步更新适配器类，维护成本反升
- 子类之间差异极大，共性极少，抽象适配器容易变成“假抽象”——每个子类都重写全部方法，适配器只剩形式
- 需要多继承能力（Java 不支持），此时应优先考虑对象适配器（组合）而非接口适配器（继承）
适配器的价值，在于明确划分“谁该负责什么”：接口定契约，抽象类管兜底，子类专精业务。写对了，代码就松而不散。
