接口与抽象类设计不当的核心表现是契约失焦与复用失效：接口塞default流程、命名泛化、承担状态；抽象类替接口兜底、耦合状态、沦为万能基类；实现类职责过载、分支摊平、空实现泛滥。
接口与抽象类设计不当，最直接的表现是类体系越来越难理解、改一处牵动十处、新增需求总要绕着旧结构打补丁。排查关键不在于数有多少层继承或实现，而在于看它们是否还在承担“契约”和“复用”的本职——一旦开始承载状态、逻辑分支、或被迫妥协适配多场景，臃肿就已发生。
看接口是否悄悄变成了“行为容器”
接口本应只声明“能做什么”，但若出现以下情况，说明它正在越界：
- 接口里塞了大量 default 方法，且彼此有调用链（比如 validate → normalize → enrich），这实际已构成一个微型流程，该抽成工具类或策略组合，而非放在接口里
- 多个实现类中，对同一 default 方法的重写只是加日志或改返回值，其余逻辑完全一致——说明这个 default 方法本不该存在，或者该由抽象类统一提供基础实现
- 接口方法命名泛化（如 handle()、process()），且不同实现类内部逻辑差异极大（订单处理 vs 文件解析），这是职责模糊的信号，应拆为更小、语义明确的接口（OrderProcessor、FileParser）
看抽象类是否在替接口“兜底”
抽象类适合封装共性逻辑，但若它频繁承担“补接口短板”的角色，体系就在失衡：
- 抽象类里写了大量 final 方法 + 模板方法，而子类只能覆盖一两个钩子，其余全是被强制绑定的流程——这本质是把可插拔的设计硬编码成了固定流水线
- 抽象类中定义了字段（尤其是可变状态），且子类依赖这些字段做判断（如 if (this.mode == SYNC)），说明本该由策略/配置驱动的行为，被耦合进了继承树
- 为让子类少写代码，抽象类不断添加 protected 工具方法，最后变成“万能基类”，连日志、HTTP 调用、缓存操作都包了——此时应剥离为独立服务，用组合替代继承
看实现类是否在“跨层缝合”
当具体类同时实现多个接口、又继承抽象类，还手动注入一堆服务时，它很可能在承担本不属于它的整合职责：
立即学习“Java免费学习笔记（深入）”；
- 一个 PaymentService 类既 implements Chargeable、Refundable、Notifyable，又 extends BaseTransactionHandler，还持有 CacheClient、RiskEngine、SmsSender —— 这不是复用，是职责过载
- 实现类里大量出现 if-else 根据类型分支（如 if (payment.getType() == ALIPAY) {...} else if (payment.getType() == WECHAT) {...}），说明本该用策略模式隔离的变体，被强行摊平在同一个类里
- 为了适配新接口，老实现类不得不重写一堆空方法（@Override public void onExpire() {}），这是接口粒度过粗的铁证，应按场景拆分小接口
用编译与运行时线索反向验证
静态结构看不出问题，但异常和字节码会说话：
- 出现 AbstractMethodError：不是代码没写完，而是接口加了新抽象方法，但部分实现模块未重新编译——暴露了“接口升级无治理”的流程缺陷
- 用 javap -s 查看实现类字节码，发现它实现了 5 个接口，但其中 3 个只各有一个空实现方法——这些接口大概率是为“未来扩展”提前定义的，实际并未带来复用价值
- 代码评审中看到 service::doWork 这类宽泛方法引用，且该方法在 4 个不同业务流中被调用，说明抽象层级错位，契约没有收敛到真实场景
