Java继承解耦的核心是用接口定义行为契约、依赖注入替代new、抽象基类仅作技术支撑。如日志用EventLogger接口而非含字段的抽象类，业务类只持接口引用，通过构造器注入或Spring管理实现替换；Runnable模式分离任务与执行。
Java 中继承导致的代码耦合，核心问题在于编译期就锁定了父子关系，子类被迫继承不需要的字段、方法甚至初始化逻辑，改父类一处，子类可能大面积报错或行为异常。解耦的关键不是“少用继承”，而是把“能做什么”和“怎么做”分开，让调用方只依赖行为契约，不绑定具体实现。
用接口替代继承，只定义行为契约
接口里不放字段、不写构造器、不设 protected 方法，只声明公开能力。比如日志功能，定义 EventLogger 接口，只含 log(String event)；而不是在抽象类里预置 filePath、bufferSize 等配置字段——这些属于实现细节，不该污染契约。
- 避免“大而全”接口，如 CommonService，堆砌 save/update/sendEmail
- 按场景拆分：订座系统中，前台页面只需 SeatReservation，后台调度只需 SeatLockManager
- 每个实现类完全自治：FileLogger 和 SlackLogger 互不知晓，也不共享基类中的格式化工具
把 new 拆掉，把创建权外移
业务类里写 new UserServiceImpl()，等于同时绑定了实现类、构造逻辑、生命周期——换数据库、加缓存、写单元测试都得改源码。必须让业务类只持有接口引用，创建交给外部。
- 构造器注入：业务类的构造函数参数声明为接口类型，由外部传入实现实例
- 工厂模式：通过 DataFactory.createUserService() 获取实例，避免硬编码类名
- Spring 管理：用 @Autowired 注入接口类型，容器自动匹配 Bean，替换实现时业务代码零修改
继承不是不能用，但要有严格边界
若多个子类确有稳定共用的状态与算法骨架（比如 HTTP 客户端统一处理重试、超时、Header 注入），可设计抽象基类，但必须满足：
立即学习“Java免费学习笔记（深入）”；
- 该基类本身不被外部直接依赖
- 所有 public 方法标记为 final，只留 protected 钩子供子类定制
- 它不实现任何业务接口，只是纯技术支撑层
- 真正的业务契约，仍由上层接口承担
配合 Runnable 思想做进一步分离
继承 Thread 让业务类强绑定线程管理；而实现 Runnable 后，任务类只是普通 Java 类，不 import Thread、不调用 start()，只专注“做什么”。它可复用于线程池、定时器、异步回调，测试时直接调用 run() 即可验证逻辑。
- 任务与执行分离，是“解耦”的典型范式
- 执行策略（谁来跑、何时跑、怎么跑）由外部控制，任务本身无感知
- 支持依赖注入与组合，天然契合高内聚、低耦合原则
