多态是将“同一行为、多种实现”从主逻辑剥离的手段，提升内聚、降低耦合；需通过清晰接口、依赖注入、合理分层与克制设计落地，避免伪多态和职责扩散。
多态本身不是目的，而是把“同一行为、多种实现”这件事从主业务逻辑里剥离出来的手段。它让每个类只专注一种变化，不掺杂其他分支判断，自然就提升了内聚；同时用接口统一协作契约，调用方不用知道具体是谁在干活，依赖变松了，耦合也就降下来了。
用策略接口替代条件分支
当一个方法里反复出现 if (type == "sms")、switch (channel) 这类代码，说明职责已经扩散——它既要做业务判断，又要管不同渠道的发送细节。这不是多态，是内聚失效的信号。
- 定义清晰的业务接口，比如 NotificationSender，只声明
send(User user) - 为每种渠道写独立实现：EmailSender、SmsSender、PushSender，各自封装协议、重试、限流等细节
- 业务类（如 OrderService）只持有 NotificationSender 接口，运行时由 Spring 或工厂注入具体实现
- 新增微信通知？加个 WechatSender 实现接口，改配置或注解即可，原业务代码完全不动
让多态成为可插拔的协作方式
多态的价值不在“能换实现”，而在“换实现不惊动调用方”。这要求接口设计克制、依赖注入干净、包结构合理。
- 接口方法必须聚焦输入输出，不暴露技术细节（例如返回
Result<Order>，而不是ResponseEntity<Map<String, Object>>） - 所有依赖通过构造函数注入，类型必须是接口，禁止 new 具体实现类
- Controller 层只依赖 Service 接口，Service 层只依赖 Repository/Validator/Strategy 接口，不越层拿 JdbcTemplate 或 RedisTemplate
- 接口所在包名体现业务域（如
com.example.order.strategy），实现类放在对应 infra 或 impl 包下，边界一目了然
避免伪多态：继承滥用与接口膨胀
不是所有“多个类实现同一个接口”都算有效多态。如果接口方法太多、职责模糊，或者子类只是简单覆盖父类方法而没真正分离关注点，反而会增加理解成本和维护风险。
立即学习“Java免费学习笔记（深入）”；
- 一个接口原则上不超过 5 个方法；超过就说明它在悄悄承担多个角色，该拆
- 拒绝 Helper、Utils、Manager 这类泛化命名，接口名要带业务语义，比如 PaymentProcessor、RefundPolicy
- 优先组合而非继承：用字段持有策略接口，比 extends 一个抽象基类更灵活、更可控
- 测试时，如果一个单元测试要 mock 超过 3 个协作对象，大概率是类职责太重，多态没用对地方
配合 AOP 和依赖注入落地多态价值
多态要真正起效，离不开基础设施的支持。硬编码的 new、静态工具调用、跨层持有底层对象，都会让策略接口形同虚设。
- @Transactional、@Valid、日志埋点这些横切逻辑，用 AOP 统一处理，别塞进 send() 方法里干扰核心流程
- 参数校验用 @Valid + 自定义注解，而不是在 NotificationSender.send() 开头写一堆 if (user == null)
- 构造器注入优于字段注入：确保依赖不可变、非空，避免运行时 NPE
- 运行时选型靠 @Qualifier 或工厂方法，而不是在业务代码里 if-else 判断再 new —— 那只是把分支从一处搬到另一处
