接口解决“能做什么”，是能力契约，不关心实现；抽象类解决“怎么开始做”，是带骨架的半成品父类，支持状态与部分实现。
大厂面试问接口和抽象类，不是让你背定义，而是看你怎么理解设计意图、演化逻辑和真实场景的取舍。核心就一点：接口解决“能做什么”，抽象类解决“怎么开始做”。
接口是契约，不是模板
很多人说“接口是完全抽象的类”，这容易误导。接口本质是能力声明——它不关心谁实现、怎么实现，只强制约定行为签名。Java 8 后 default 和 static 方法没改变这点，只是让契约更灵活。
- default 方法是“可选的默认行为”，用于向后兼容（比如 Collection 接口加 stream()），不是为了复用逻辑；真要复用，请用组合或工具类
- 接口不能有构造器、不能存状态（字段只能是 public static final）、不能初始化块——这些限制都在强调：它只管“协议”，不管“实例”
- 当被问“为什么接口不能有 protected 方法？”，答案不是语法限制，而是语义冲突：protected 暗示“子类可见”，但接口没有继承链意义上的“子类”，只有实现者，而实现者天然可见 public 成员
抽象类是半成品，带骨架的父类
抽象类是“有共同基础的类型家族”的起点。它允许封装共用状态、提供部分实现、控制继承结构，甚至定义模板方法模式。
- 可以有构造器（用于初始化共享字段）、普通字段、protected 方法、静态代码块——所有这些都在支持“构建一个可复用的基底”
- 抽象类适合表达 is-a 关系且存在共性逻辑的场景，比如 AbstractList：它实现了 size()/isEmpty() 等通用方法，把 get(int) 留给子类实现，这就是典型的“骨架+钩子”
- 被问“抽象类能替代接口吗？”——技术上有时可以，但设计上不该。比如你让多个无关类型（Payment、Notification、Logger）都继承同一个抽象类，就破坏了单一职责和继承语义
选谁？看关系本质，而不是“能不能”
面试官常抛具体场景，比如：“设计一个消息推送系统，支持短信、邮件、站内信，未来还要加微信、AppPush。怎么建模？”
立即学习“Java免费学习笔记（深入）”；
- 先抓核心：它们共同点是“都能 send(Message)”，差异在渠道、配置、重试策略——这是典型的能力契约 → 定义 MessageSender 接口
- 再看共性：短信和邮件都要处理模板渲染、变量替换、发送前校验 → 可提取 AbstractTemplateBasedSender 抽象类，封装 renderTemplate()、validate() 等逻辑，让子类专注 send() 的渠道细节
- 注意：站内信可能走数据库写入，不需要模板，就不继承那个抽象类，只实现接口——这正是接口解耦的价值
高阶追问常落点在演进与边界
资深面试官会模拟真实迭代压力，比如：“现在要给所有 sender 加监控埋点，怎么改？如果某天发现邮件 sender 的连接池管理逻辑也想复用，怎么办？”
- 埋点不侵入业务逻辑 → 用装饰器模式包装接口实现，或用 AOP。强行在抽象类里加 monitor() 方法，会让所有子类被动承担无关职责
- 连接池是另一维度关注点 → 提取 ConnectionPoolManager 类，通过组合注入到需要的 sender 中。别试图用多层抽象类去“堆叠”横切能力
- 当抽象类和接口都出现时，优先让类 继承抽象类 + 实现接口，而非用接口继承接口——后者易导致“接口爆炸”，前者语义清晰：我是一个 XXX（is-a），同时具备 YYY 能力（can-do）
