面向对象编程的核心难点在于职责划分与设计模式的合理应用：类应只封装一个变化原因，优先用组合替代继承，等出现第三个相似实现再抽象模式，避免过早设计导致维护困难。
面向对象编程不是画个类图就完事了，真正卡住人的地方，是不知道什么时候该拆类、什么时候该合并，以及设计模式用错反而让代码更难改。
类和对象分不清边界，是因为没想清楚“谁负责什么”
常见错误现象：Student 类里塞了成绩计算、数据库保存、PDF导出逻辑；ReportGenerator 又重复写一遍成绩算法。结果改一个地方，三处都要动。
使用场景：只要出现“这个类既做 A 又做 B 还要 C”，基本就是职责混杂。
实操建议：
- 每个类只封装一个明确的**变化原因**——比如成绩规则变、导出格式变、存储方式变，这些都该是不同类
- 问自己：“如果我要换掉数据库，哪些类完全不用改？” 答案之外的类，大概率越界了
-
new操作符出现在业务逻辑里（比如new PdfExporter()），说明创建细节泄露了，该上工厂或依赖注入
继承滥用导致修改像拆炸弹
常见错误现象：为了复用几行代码，建了 BaseService → UserBaseService → AdminUserBaseService 三层继承；加个新字段就得翻三遍构造函数。
参数差异：super() 调用链越长，子类越难预测父类行为；而组合中 private final DataProcessor processor 的行为是封闭且可替换的。
实操建议：
- 优先用组合：把共用逻辑抽成独立类，通过字段持有，而不是 extends
- 只在“确实是 is-a 关系”时用继承——
Dog是Animal，但PaymentService不是LoggingService - 警惕
protected成员：它本质是给子类留的后门，后门越多，父类越不敢动
设计模式套用失败，八成栽在“提前抽象”上
常见错误现象：还没写完两个支付渠道，就急着搞 PaymentStrategy 接口 + PaymentContext；结果新增微信支付时发现，支付宝和银联的参数结构根本不兼容，接口得大改。
性能 / 兼容性影响：过度抽象会增加间接层，调用栈变深，调试时跳转 5 次才到实际逻辑；更重要的是，早期抽象往往基于猜测，不是真实需求。
实操建议：
- 等出现**第三个相似实现**再提取模式——两个用 if-else，三个开始考虑策略/工厂
- 先写具体实现，再用 IDE 的 Extract Interface 功能反向推导协议，比正向设计更贴近实际约束
- 模式命名要直白：
RetryableHttpCaller比AbstractInvokerDecorator更容易被后续维护者理解
最常被忽略的一点：类图里画得再漂亮，如果不能对着生产日志快速定位到 OrderService.calculateDiscount() 这一行为什么返回了负数，那这张图就只是装饰。
