开闭原则要求类对扩展开放、对修改关闭，即通过新增子类或实现接口来支持新功能，而非修改原有代码；抽象（接口/抽象类）定义稳定契约，继承与模板方法提供安全扩展路径，组合与继承需依变化点合理选用，抽象应聚焦可预期的变化且粒度适中。
开闭原则（Open/Closed Principle，OCP）是面向对象设计五大原则（SOLID）之一，核心是：**类应该对扩展开放，对修改关闭**。这意味着当需求变化时，我们应通过添加新代码（如新增子类、实现新接口）来支持新功能，而不是反复修改已有稳定类的源码。抽象与继承是实现这一原则最经典、最直接的技术手段。
用抽象类或接口定义稳定契约
抽象是开闭原则的基石。把系统中可能变化的行为提取为抽象（接口或抽象类），让具体实现去负责细节，而调用方只依赖抽象——这样，新增行为只需新增实现类，无需改动使用方或原有逻辑。
- 例如，一个订单支付模块，不写死“微信支付”或“支付宝支付”，而是定义 PaymentProcessor 接口，含 process() 方法；
- 后续增加 Apple Pay 或数字货币支付，只需新增 ApplePayProcessor 类并实现该接口；
- 订单服务类（OrderService）持有 PaymentProcessor 引用，运行时注入具体实例——它完全不知道也不需要修改自身代码。
用继承扩展行为，而非修改原有逻辑
当已有类具备通用能力，但某些子场景需差异化处理时，可通过继承+多态延伸功能，避免在原类中堆砌 if-else 或 switch 分支。
- 比如基类 ReportGenerator 提供通用的数据获取、格式化骨架方法，将关键步骤（如导出格式）声明为 abstract；
- 子类 PdfReportGenerator 和 ExcelReportGenerator 各自实现 export()，互不影响；
- 新增 CSV 导出？只需加一个 CsvReportGenerator，不碰基类、不改已有子类、不改调用方。
组合优于继承？别误读——继承仍是 OCP 的合法主力
有人因“组合优于继承”而回避继承，但这不等于继承不能支撑开闭原则。关键不在“用不用继承”，而在“是否通过抽象隔离了变化点”。只要父类足够稳定（只定义契约，不含易变逻辑），子类就是安全的扩展入口。
- 反例：父类里写了大量业务判断和硬编码分支，子类重写方法却要绕过这些逻辑——这不是开闭，是紧耦合；
- 正例：父类是模板方法模式（Template Method），钩子方法（hook method）留给子类定制，主流程不变——这正是 OCP 的典型实践；
- 抽象类 + 模板方法 + 具体子类 = 清晰的扩展边界，也是 Java/Python/C# 等语言中被长期验证的有效路径。
警惕“伪扩展”：抽象不是越多越好
滥用抽象反而违背开闭原则——过度设计会让系统难以理解，新增功能仍需改多处。抽象的价值在于识别**真正会变、且变化方向可预期**的部分。
- 不要一上来就为所有类建接口：“User”类要不要 IUser 接口？先问：未来是否会出现多种 User 实现（如 MockUser、RemoteUser、CachedUser）且它们会被同一套逻辑统一处理？
- 优先从明确的扩展需求出发：比如日志输出要支持控制台、文件、远程服务——这时定义 Logger 接口就合理；
- 抽象粒度要适中：太粗（如一个 ISystem 接口包揽所有）失去约束力，太细（每个方法一个接口）导致实现爆炸——以“一类可替换的行为”为单位抽象即可。
不复杂但容易忽略：开闭不是靠一次设计就永远成立，而是靠持续识别变化点、及时提取抽象、严格遵守依赖倒置（DIP）来维持。每一次新增功能，都问问自己：我是在加类，还是在改旧类？答案决定你离开闭原则有多近。
