多态是支撑业务代码可扩展性的核心机制，通过接口或抽象类定义行为契约，运行时动态选择实现，新增业务只需添加类并注册，无需修改原有逻辑。
多态是面向对象编程中支撑业务代码可扩展性的核心机制。它让新增业务逻辑无需修改已有代码，只需添加新类并遵循统一接口，就能无缝接入现有流程。
用接口或抽象类定义行为契约
把变化点抽象成接口（如 PaymentStrategy），或抽象基类（如 NotificationSender），只声明“做什么”，不关心“怎么做”。所有具体实现（微信支付、短信通知）都必须实现该契约。
- 接口比抽象类更轻量，适合行为差异大、无共用逻辑的场景
- 抽象类适合有部分通用逻辑（如日志记录、参数校验）需要复用的情况
- 命名体现业务意图，比如 OrderValidator 比 CheckRule 更易理解
运行时动态选择具体实现
避免硬编码 new 具体类型，改用工厂、策略映射或依赖注入容器来解耦创建逻辑。例如根据订单类型返回对应处理器：
- 用 Map
缓存已注册的处理器，key 是业务标识（如 “VIP”、“团购”） - Spring 中用 @Qualifier 或 @Primary 控制 Bean 注入，配合 @Profile 实现环境隔离
- 简单场景可用简单工厂方法，但注意别让它变成新的 if-else 集中地
新增业务只需加类，不碰老代码
当要支持“跨境订单自动报关”时，只需新建 CustomsDeclarationHandler 实现 OrderHandler 接口，再注册到策略映射中。原有下单主流程完全不用动，测试也只需验证新类行为。
- 每个新类职责单一，只关注自身业务规则，不掺杂调度或判断逻辑
- 单元测试聚焦该实现本身，用 Mock 隔离外部依赖（如海关接口）
- 上线前通过开关控制是否启用，降低风险
警惕多态滥用带来的隐性成本
不是所有分支都适合用多态。如果只有两三种情况且极少变动（如“男/女”性别处理），硬套策略模式反而增加理解负担。
- 先评估变化频率：半年内预计新增 ≥3 种实现，才值得抽象
- 检查调用方是否真需要统一处理——若各实现之间毫无共性，说明抽象层次错了
- 避免过度分层，比如为“发短信”又单独抽象一层 SmsChannel，而实际只需一个 NotificationService
不复杂但容易忽略：真正让多态发挥价值的，不是语法层面的 override，而是团队对“哪些该变、哪些不该动”的共识，以及配套的注册、发现和灰度机制。
