一眼看出代码违反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 字段或模板方法，导致旧子类行为被意外影响。
- 比如抽象类
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已失效
