抽象类用于定义固定流程和共享状态，接口用于定义契约和正交能力；模板方法模式中抽象类搭骨架、接口划边界，策略模式中接口为主角、抽象类作内部优化，工厂模式中三者分层协作。
面试时被问“接口与抽象类怎么用”，光背语法区别会显得单薄。真正加分的回答，是把它们放进设计模式里讲清楚——谁在哪儿出现、为什么非它不可、换掉会出什么问题。
模板方法模式：抽象类搭骨架，接口划边界
这是抽象类最不可替代的场景。比如支付流程：校验→调用第三方→处理回调→更新订单状态。这个顺序不能变，但每一步的具体实现因渠道而异。
- 抽象类（PayTemplate）定义整个流程，把变化点声明为
abstract void doPay()、abstract void handleCallback() - 具体子类（AlipayTemplate、WechatTemplate）只管填空，不用操心流程错乱
- 对外暴露的却是
PaymentService接口，只含pay()、refund()等契约方法
这里抽象类解决“怎么一步步做”，接口解决“别人怎么调你”。缺了抽象类，流程复用就散了；缺了接口，上层代码就得硬耦合到某个具体实现。
策略模式：接口当主角，抽象类作配角
策略模式的核心是运行时切换算法，比如折扣计算：满减、会员折、限时券。它们之间没有继承关系，只共享“能算折扣”这一能力。
立即学习“Java免费学习笔记（深入）”；
-
DiscountStrategy接口是绝对核心，客户端只依赖它，才能自由替换策略 - 如果多个策略都要校验用户等级、记录日志、格式化金额，可以加一个
AbstractDiscountStrategy抽象类封装这些共性逻辑 - 但注意：抽象类只是内部优化，不改变策略可插拔的本质；客户端代码完全感知不到它的存在
没有接口，策略就失去意义；有了抽象类，只是让策略写起来更干净——它可有可无，但绝不能替代接口。
工厂+抽象类+接口：三层分工一气呵成
以解析器为例：CSV、JSON、XML 解析逻辑不同，但都有空输入检查、异常包装、日志记录等通用动作。
- 顶层是
DataParser接口，定义parse()和getFormatName()，使用者只认这个契约 - 中间是
AbstractDataParser抽象类，把校验、日志、异常处理写死，只留doParse()让子类实现 - 底层是
JsonParser等具体类，继承抽象类 + 实现接口 - 工厂返回
DataParser类型，新增 YAML 解析只需加个新类，其他代码零改动
这三层像齿轮咬合：接口保扩展性，抽象类保复用性，工厂保创建灵活性。三者缺一不可，但角色毫不重叠。
选型口诀：问三个问题就清楚
遇到新需求，别纠结语法，直接问自己：
- 这个能力以后会不会被完全无关的类需要？比如“可重试”“可审计”——选接口
- 这几个类之间有没有共享状态（如配置、连接池）或固定流程（如统一验签、幂等控制）——选抽象类
- 一个类是否要同时拥有多种正交能力？比如“既是支付渠道，又支持异步回调，还能生成对账单”——必须靠接口组合
接口回答“能做什么”，抽象类回答“是什么”，设计模式就是把这两个答案自然地编进代码结构里。
