一眼看出代码违反OCP：若新增功能需修改现有if-else/switch分支或public方法体，如PaymentService.process()加支付方式、Shape.draw()增图形类型，即违背OCP。
Java里怎么一眼看出代码违反了OCP？
看有没有 if-else 或 switch 块里硬编码新行为——比如新增一种支付方式，就得改 PaymentService.process() 里的分支逻辑；或者加个新图形，就要往 Shape.draw() 方法里塞 if (type.equals("pentagon"))。这种“改老代码才能加功能”的写法，就是OCP的红灯。
- 典型信号：每次加需求都要打开已有类、改
public方法体、动private字段逻辑 - 本质问题：把“变”的东西（如支付类型、导出格式、校验规则）和“不变”的框架（如订单流程、报表生成入口）混在同一个类里
- 后果不是立刻报错，而是改完后单元测试大面积失败，或者上线后老功能悄悄出错
用接口+多态实现OCP最稳的三步
核心不是“用不用接口”，而是“谁依赖谁”。高层模块（比如 OrderProcessor）必须只依赖抽象（PaymentStrategy），具体实现（AlipayStrategy、CodStrategy）由外部注入，不被高层知晓。
- 第一步：定义接口，方法签名要聚焦行为，别塞参数细节——
void pay(Order order)比void pay(Order order, String channel, BigDecimal fee)更符合OCP - 第二步：每个新策略写独立类，实现接口，内部只管自己那块逻辑——
CodStrategy不需要知道支付宝的秘钥怎么验签 - 第三步：用工厂、Spring
@Bean或构造函数注入把具体实现塞进去，OrderProcessor类本身一行都不用动
为什么抽象类比接口更容易踩坑？
抽象类自带默认实现和状态，容易让人误以为“加个新子类就能搞定”，结果新子类偷偷复用了父类的 protected 字段或模板方法，导致旧子类行为被意外影响。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 比如抽象类
ReportGenerator里有个protected Map<string object> cache</string>，PdfReport和ExcelReport都在用——新加JsonReport一改 cache 结构，前两个就崩 - 接口更安全：没状态、没实现，强制每个实现类从零写清自己的逻辑边界
- 真要用抽象类，务必把可变部分抽成 protected abstract 方法，把不变骨架锁死
Spring项目里最容易忽略的OCP破环点
不是没写接口，而是接口被“过度实现”——比如一个 UserRepository 接口，本该只管增删改查，结果里面塞了 findActiveUsersByRegion()、findVipUsersWithCoupon() 这种带业务语义的方法。后面加个“海外用户统计”，又得改接口、改所有实现类。
立即学习“Java免费学习笔记（深入）”；
- 正确做法：接口只暴露
findAll(Specification<user> spec)</user>或findByQuery(UserQuery query)，把查询条件封装进对象，新条件直接加字段 - 别让接口变成“需求快照”，它应该是稳定的契约，不是需求列表
- 如果发现接口方法名里带“VIP”“海外”“2025活动”这类词，基本可以判定OCP已失效
