Java继承与接口选择技巧

Java中选择继承还是接口，本质是回答“子类是什么”还是“子类能做什么”——is-a关系用extends，has-a或can-do关系优先选implements；接口适用于多类共享行为契约但无父子关联的场景（如Runnable），支持多重实现与松耦合设计，而继承仅在语义上确为“一种”时才安全使用，否则易引发设计僵化与维护灾难；抽象类则介于两者之间，适合有共通状态和模板逻辑的同类体系；尤其要注意：公开接口一旦发布便难以扩展抽象方法，因此契约设计应小而专、渐进演进，而非贪大求全。

Java里该用继承还是接口，关键看你要表达的是“是什么”还是“能做什么”——前者选 extends，后者选 implements；混淆这两者，后期改起来比修线程安全还头疼。

什么时候必须用接口（interface）

当多个类需要共享同一组行为契约，但彼此没有天然的父子关系时，接口是唯一合理选择。比如 Runnable、Comparable、Serializable，它们不关心实现类“是谁”，只约束“能干什么”。

• 一个类可以 implements 多个接口，但只能 extends 一个类——这是 Java 单继承限制下的刚需出口
• 接口适合定义回调、策略、事件监听等松耦合场景，例如 OnClickListener 在 Android 中被任意 UI 组件复用
• JDK 8+ 接口可含 default 方法和 static 方法，但不能有实例字段或构造器——别试图在接口里塞状态

什么时候该用继承（extends）

只有当你能明确说出“子类是一种父类”时，才考虑继承。比如 Dog extends Animal 成立，但 LogUtil extends FileHandler 就是典型误用——工具类不是文件处理器的一种。

• 继承会强绑定子类与父类的实现细节，父类加个 protected 字段或改个 final 方法，下游可能直接编译失败
• super() 调用链、构造器顺序、方法重写可见性（如 private 方法不可被重写）都是隐性成本
• 若只是为了复用代码，优先考虑组合（has-a）而非继承（is-a），比如把通用逻辑抽成 Helper 类，再由业务类持有它

接口和抽象类（abstract class）怎么选

抽象类是继承和接口之间的灰色地带：它既能定义行为契约（抽象方法），又能提供默认实现和状态（字段、构造器、protected 成员）。

• 如果一组子类共享大量模板代码（如 HTTP 客户端的重试逻辑、日志埋点），且确定它们属于同一语义类别，用抽象类更合适
• 抽象类仍受单继承限制，不能替代接口解决多行为建模问题
• 抽象类的构造器可用于强制子类传入必要依赖（如 AbstractService(Config config)），接口做不到这点
• 注意 JDK 9+ 接口支持 private 方法，可用于封装 default 方法的共用逻辑，但无法替代抽象类的状态管理能力

最常被忽略的一点：接口一旦发布上线，新增抽象方法就是二进制不兼容变更——所有实现类必须立刻跟进，而抽象类加 default 或 protected 方法相对温和。所以对外暴露的公共契约，宁可一开始多定义几个小接口（Readable、Writable），也别堆成一个巨无霸 IOProcessor。

理论要掌握，实操不能落！以上关于《Java继承与接口选择技巧》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！