继承导致高耦合因编译期绑定父子关系，子类被迫继承无用成员；接口解耦通过分离“能做什么”与“怎么做”，以契约替代实现，配合依赖注入实现灵活替换。
继承容易让子类和父类绑得太死，改一处可能牵动全身。接口解耦的核心思路是：把“能做什么”从“怎么做”里剥离开，让调用方只依赖行为契约，不关心具体实现。
为什么继承容易导致高耦合
继承在编译期就锁定了父子关系，子类自动获得父类所有非私有成员——包括字段、方法甚至初始化逻辑。一旦父类调整字段名、删掉某个protected方法，或修改模板方法流程，子类很可能直接报错或行为异常。更隐蔽的问题是：子类被迫承载它根本用不到的父类能力，比如一个PaymentProcessor继承了ReportGenerator，只为复用其中两个工具方法，结果测试时得连报表逻辑一起mock。
用接口替代继承的关键操作
- 只定义行为，不带状态：接口中不放字段、不写构造器、不设protected方法。例如日志功能，定义EventLogger接口，只含log(String event)，而非在抽象类里预置filePath、bufferSize等配置字段
- 按场景拆分，拒绝大而全：避免CommonService这种堆砌save/update/sendEmail的接口。订座系统里，前台页面只需SeatReservation，后台调度只需SeatLockManager，各自只暴露真正需要的方法
- 实现类完全自治：每个实现类独立完成全部逻辑，不依赖其他实现类的内部结构。比如FileLogger和SlackLogger之间互不知晓，也不共享基类中的格式化工具
配合依赖注入真正落地解耦
光有接口不够，还得让使用方不自己new实现类。Spring中用@Autowired注入接口类型，容器自动匹配可用Bean；手动管理时可通过工厂方法返回接口实例。关键点在于：业务类的字段声明必须是接口类型，构造函数参数也必须是接口——这样替换实现时，业务代码一行都不用改。
什么时候仍可保留继承
若多个子类确有共用的、稳定不变的状态与算法骨架（比如HTTP客户端统一处理重试、超时、Header注入），可设计一个抽象基类，但需满足：该基类本身不被外部直接依赖；其public方法全部是final，仅留protected钩子供子类定制；且该基类不实现任何业务接口，只是纯技术支撑层。真正的业务契约，仍由上层接口承担。
