开闭原则要求软件实体对扩展开放、对修改关闭，通过抽象基类定义契约、继承与多态实现行为扩展，新增功能只需添加子类而不修改原有代码，多态是其技术支点。
开闭原则（Open-Closed Principle, OCP）强调：软件实体（类、模块、函数等）应当对扩展开放，对修改关闭。它不靠修改原有代码来增加新功能，而是通过继承与多态引入新行为——这是面向对象设计中支撑可维护性与可复用性的关键机制。
用抽象基类定义稳定契约
把不变的接口或共性逻辑抽成抽象类或接口，作为所有子类共同遵守的规范。例如订单处理系统中，定义 OrderProcessor 抽象类，声明 process() 方法但不实现；具体策略（如普通订单、会员订单、跨境订单）各自继承并重写该方法。
- 抽象层屏蔽了底层变化，上层调用者只依赖抽象，不依赖具体实现
- 新增一种订单类型，只需新增一个子类，无需改动已有任何类的源码
- 避免在原类中堆砌 if-else 或 switch 分支，防止逻辑腐化
运行时多态实现行为替换
客户端代码通过父类引用调用方法，实际执行哪个子类的实现，由运行时对象类型决定。这使得“扩展”真正脱离“修改”——只要符合同一抽象，任意新子类都能无缝接入现有流程。
- 工厂类或依赖注入容器负责创建具体子类实例，调用方完全无感
- 比如日志模块中，Logger 接口被 FileLogger、DBLogger、CloudLogger 实现；切换日志方式只需改配置或构造参数，不碰业务逻辑代码
- 多态是OCP落地的技术支点，没有它，继承只是静态结构复用，无法动态插拔新能力
谨慎使用模板方法模式强化约束
当算法骨架稳定但部分步骤可变时，可在抽象类中用模板方法（template method）定义流程，把可变环节声明为 abstract 或 hook 方法，强制子类参与定制。
- 例如支付流程：executePayment() 是模板方法，内部调用 validate()、deduct()、notify()；其中 deduct() 设为 abstract，让微信支付、支付宝、银行卡各自实现扣款细节
- 既保证主流程一致，又允许局部灵活扩展，且不破坏原有类结构
- 注意避免过度抽象——只有真正稳定的部分才放进模板，否则会限制后续演化
OCP不是拒绝修改，而是把修改风险控制在抽象边界内。继承提供扩展入口，多态提供运行时绑定能力，二者结合，让系统像搭积木一样生长，而不是在旧代码上反复刮腻子。
