选接口还是抽象类取决于表达“能做什么”还是“它是谁”：接口强调能力契约与多维组合，抽象类侧重身份继承与状态逻辑复用；二者常配合使用，而非替代。
选接口还是抽象类，关键看你想表达“它能做什么”还是“它是谁”。前者用接口，后者用抽象类。它们不是替代关系，而是分工明确、常一起用的两种工具。
需要共享状态或通用逻辑时，用抽象类
当多个类天然共用字段、构造流程或基础行为，抽象类更合适。它能持有实例变量、定义构造器、封装可复用的方法，还能控制继承细节（比如 protected 字段供子类直接访问）。
- 订单系统里，AbstractOrder 可统一管理 orderNo、createTime、logOperation() 等共性内容
- 支付处理器如 WeChatPayProcessor 和 AlipayProcessor 共享风控检查入口和流水号生成规则，适合抽成 AbstractPaymentProcessor
- 想强制子类按固定步骤执行（比如校验→处理→回调），就用模板方法模式——骨架写在抽象类里，钩子方法留空让子类填
强调能力契约或多维组合时，用接口
接口只声明行为，不关心实现，也不带状态。一个类可以同时实现多个接口，适合描述角色、能力或跨领域协议。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 订单可同时具备 Refundable、Trackable、Cancelable，无需强行塞进同一继承链
- 微服务间通信、模块解耦、测试 Mock，都依赖接口作为契约——调用方只依赖 PaymentStrategy，不关心背后是微信还是支付宝
- JDK 中的 Comparable、Serializable、Cloneable 都是典型能力型接口，与具体类族无关
真实项目中，往往是“抽象类 + 接口”配合使用
大型系统既需要主干流程复用，又需要策略灵活替换。常见做法是：抽象类搭骨架，接口插策略。
- AbstractOrderService 定义下单全流程，而库存锁定方式交给 InventoryLockStrategy 接口，由 RedisLock 或 DBLock 实现类注入
- Spring 的 JdbcDaoSupport 是抽象类，封装 JdbcTemplate；PlatformTransactionManager 是接口，适配 JDBC、JTA、Reactive 多种事务机制
- 策略模式中，DiscountStrategy 是接口，而具体折扣逻辑若需共享计算模板（如满减叠加规则），可用 AbstractPercentageDiscount 作基类
别被 default 方法带偏方向
JDK 8 后接口支持 default 方法，但本质没变：它仍是无状态的契约工具。default 方法只用于轻量兼容（如 Collection 新增 stream()），不是为了替代抽象类的复用场景。
- 如果发现接口里 default 方法越来越多，还开始管理复杂逻辑或模拟状态，说明设计已越界，该重构为抽象类了
- 接口仍不能有构造器、不能有实例变量、所有字段只能是 public static final——这些硬约束决定了它扛不起“状态+行为”的复合职责
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
