开闭原则要求软件实体对扩展开放、对修改关闭，通过抽象基类定义契约、继承与多态实现行为扩展，新增功能只需添加子类而不修改原有代码，多态是其技术支点。

开闭原则（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不是拒绝修改，而是把修改风险控制在抽象边界内。继承提供扩展入口，多态提供运行时绑定能力，二者结合，让系统像搭积木一样生长，而不是在旧代码上反复刮腻子。