开闭原则指对扩展开放、对修改关闭，即新增功能应通过添加新代码实现，而非修改已验证的稳定代码；其核心是用抽象隔离变化、多态承接新行为，如支付模块通过策略模式新增支付方式而不改动原有逻辑。
开闭原则（Open-Closed Principle，OCP）是面向对象设计中最重要的原则之一，核心就一句话：对扩展开放，对修改关闭。意思是：当系统需要新增功能时，应该通过添加新代码（比如新类、新方法）来实现，而不是去改动已有、经过验证的稳定代码。
为什么不能随便改老代码？
已有模块往往已被测试、上线、依赖其他组件。直接修改它可能引发连锁问题——比如修复一个bug，却意外破坏另一个功能；或者让调用方因接口变更而编译失败。开闭原则不是拒绝变化，而是把“变”引导到安全路径上：用抽象隔离变化，用多态承接新行为。
怎么做到“对扩展开放”？
关键靠抽象和多态机制：
- 定义稳定的抽象（如接口或抽象类），封装可变行为的契约
- 每种具体行为由独立子类实现，新增功能只需加新子类，不碰旧类
- 运行时通过多态（如工厂、策略模式）动态选择实现，调用方只依赖抽象
例如：支付模块定义 PaymentStrategy 接口，已有 AlipayStrategy 和 WechatPayStrategy；要支持银行卡支付，只需新增 CardPayStrategy 类并注册进策略上下文——原有代码一行都不用改。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
“对修改关闭”不是绝对禁止修改
它反对的是为新增功能而修改已存在、被广泛使用的类或方法逻辑。但以下情况仍需修改，且符合OCP精神：
- 修复缺陷（Bug Fix）
- 重构提升可读性或性能（不改变外部行为）
- 调整抽象层设计（如抽取新接口），只要不影响下游依赖的契约
真正的风险点在于：在 OrderService.process() 里硬编码新增 if-else 判断支付类型——这会让每次加一种支付方式都得改这个方法，明显违反OCP。
常见落地模式与陷阱
策略模式、模板方法、观察者、工厂方法等都是支撑OCP的典型结构。但要注意：
- 抽象粒度太粗（如一个接口塞10个方法），会导致子类被迫实现无用方法，违背接口隔离
- 抽象设计过早或脱离实际场景，会增加不必要的复杂度
- 过度追求“永不修改”，反而让扩展变得笨重——OCP是指导思想，不是教条
本质上，OCP考验的是对业务变化点的预判能力，以及用抽象提前划好“可变边界”的设计功力。
基本上就这些。理解开闭原则，不是背概念，而是养成一种习惯：每次加功能前，先问自己——这个变化，能不能不碰现有类，只靠加一个类、实现一个接口来完成？
