设计模式不直接提升开发效率，其核心价值在于降低中长期协作与维护成本；适用工厂模式的场景是对象创建逻辑复杂或需按环境/配置切换实现类，而简单对象如ArrayList无需工厂。
设计模式本身不直接提高开发效率，反而在初期增加思考成本；它的价值在于降低中长期协作与维护成本——尤其当团队规模扩大、需求频繁变更时。
什么时候该用工厂模式而不是 new 一个对象
当你发现同一段代码里反复出现 new SomeServiceImpl()，且实现类可能随环境（测试/生产）或配置切换时，就该考虑工厂。硬编码具体类型会让后续替换成本陡增，比如换成 MockService 或 CacheDecorator 都得改多处。
- 适用场景：对象创建逻辑复杂（需读配置、判条件、组装依赖）
- 避免滥用：简单对象如
new ArrayList()没必要套工厂 - 注意点：Spring 的
@Bean方法本质就是工厂方法，别重复造轮子
为什么观察者模式常导致内存泄漏
Java 中手动实现观察者时，如果被观察者持有了 Observer 的强引用，而观察者又持有 Activity、Fragment 或大对象的引用（比如 Android 场景），就容易引发泄漏。JVM 无法回收被观察者，进而卡住整个链路。
- 典型错误：
subject.addObserver(this)后忘记removeObserver() - 推荐做法：用
WeakReference存储观察者，或改用 Guava 的EventBus/ Spring 的@EventListener（自动解绑） - 验证方式：用 MAT 分析堆转储，查
Subject实例是否意外持有已销毁 UI 组件
策略模式 + 枚举比 if-else 更难维护？
不是更难，而是把“分支逻辑分散到多个类”换成了“分支逻辑集中在枚举定义里”。关键看谁负责维护策略选择逻辑——如果判断条件本身会变（比如新增一种支付方式），枚举+策略就比散落各处的 if (type == "alipay") 更易定位和测试。
立即学习“Java免费学习笔记（深入）”；
- 正确用法：枚举值对应策略实现，构造器注入具体
PaymentHandler - 常见翻车：枚举里写大量业务逻辑，违背单一职责
- 性能提示：枚举实例是单例，无创建开销；但反射获取枚举值（如
valueOf()）有异常成本，建议用Map缓存
真正拖慢开发的从来不是模式本身，而是过早抽象、脱离实际调用链的“为模式而模式”。先写出三个以上相似逻辑块，再动手提取——这时候你才真正知道接口该怎么定义、哪些该变哪些不该变。
