开闭原则（ocp）要求软件实体对扩展开放、对修改关闭；java中通过接口定义稳定契约、多态实现运行时行为切换、工厂或依赖注入解耦对象创建，新增功能只需添加实现类而不修改原有代码。
开闭原则（OCP）在 Java 面向对象实践中，不是一句抽象口号，而是指导你“怎么组织类、接口和继承关系”的具体准则。它直指一个现实问题：需求总会变，但改老代码风险高、测试成本大、容易牵一发而动全身。OCP 给出的解法很明确——用新增代替修改，靠抽象约束行为，借多态切换实现。
抽象是 OCP 的锚点
没有抽象，就没有稳定的扩展基础。Java 中的 interface 或 abstract class 就是这个锚点：
- 它们定义一组契约（方法签名），不包含具体逻辑，因此本身不会因业务变化而频繁改动；
- 所有具体实现类都必须遵守这份契约，保证调用方（比如业务服务类）只依赖抽象，不依赖具体；
- 当新增功能时，只需写一个新实现类，实现相同的接口或继承同一抽象类，老代码完全不动。
继承提供可复用的扩展骨架
继承不是为了代码复用而用，而是为有规律的变化预留扩展路径：
- 如果多个子类共享相同流程但部分步骤不同（如“支付流程”中校验→扣款→通知），适合用 模板方法模式：父类定义 final 模板方法，把可变步骤声明为 abstract，子类只重写这些步骤；
- 避免让子类重写核心逻辑或破坏父类不变量；继承应体现 “is-a” 关系，且父类职责稳定；
- 注意：梅耶最初强调的是“通过继承新建类来扩展”，但现代实践更倾向组合+接口，继承仅用于真正共性明确、层次清晰的场景。
多态是运行时扩展的关键机制
多态让“新增功能”能无缝接入原有流程，无需修改调用侧代码：
- 业务类持有抽象类型引用（如
PaymentStrategy strategy），而不是具体类型（如AlipayStrategy）； - 通过工厂、配置或依赖注入动态传入不同实现，运行时自动调用对应子类方法；
- 新增微信支付？加个
WechatPaymentStrategy实现接口，改配置或注入点即可，OrderService.pay()方法一行都不用动。
警惕伪扩展：哪些做法违背了 OCP
表面新增了类，实际仍绕不开改老代码，说明抽象没立住：
- 新增功能后，不得不在原有 switch/case 或 if-else 中加分支判断类型；
- 调用方需要显式 new 具体子类，或硬编码类型名；
- 抽象接口随每个新需求不断添加方法，导致旧实现类被迫抛 UnsupportedOperationException；
- 为兼容新行为，在父类里加 flag 字段和条件逻辑——这等于把变化点暴露到稳定层。
本质上，OCP 是一种设计节奏：先识别稳定契约（抽象），再把变化封装进独立单元（实现类），最后靠多态完成解耦集成。它不追求一步到位的完美架构，而是在每次需求迭代中，有意识地把“变”与“不变”切分开——改的永远是新地方，稳的始终是老地方。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
