核心是把变化抽出来，让老类只做不变的事——存数据、暴露标准接口，所有新逻辑由外部新增的类承担。

识别并抽象稳定契约

先看哪些地方会变：支付方式、金额舍入规则、校验条件、日志输出格式……这些不是数据类该管的，而是行为。为它们定义统一接口，比如 PaymentStrategy、AmountRoundingStrategy、ValidationRule。

• 接口方法要简洁通用，例如 round(BigDecimal value)，别塞 context 或 flag 参数
• 命名体现职责，如 Formatter，而不是 JsonFormatter
• 接口里不放业务字段（如 isForFinance），那是把变化又塞回抽象层

用策略模式组织新功能

每个新业务写一个独立类，实现上面定义的接口。老代码完全不知道它的存在，只依赖接口类型。

• 加微信支付？写个 WechatPayment 类，实现 PaymentStrategy
• 加税务舍入？写个 TaxRounding 类，实现 AmountRoundingStrategy
• 所有新类和旧类物理隔离，编译、测试、部署互不影响

通过依赖注入或注册表动态接入

运行时决定用哪个实现，而不是硬编码在业务逻辑里。

• Spring 中用 @Service("wechat") 注册，再用 @Qualifier("wechat") 注入
• .NET Core 里注册为 ISingleton<PaymentStrategy>，按名称解析
• 或自建策略注册表：StrategyRegistry.get("payment.wechat")，启动时自动扫描加载
• 配置文件控制切换，比如 YAML 里改 payment.strategy: alipay 就生效

守住变量的“哑”本质

数据类（如 Order、Amount）不该有 if-else 分支，也不该持有语义字段。

• 删掉 order.isForFinance 这类字段，它让变量承担判断职责
• 不在 Amount.round() 里写 switch，而是调用注入的 roundingStrategy.round(this.value)
• 让变量真正成为容器，行为全部外移——这是 OCP 落地最常被忽略的一环