设计模式是解决问题的思路总结，而非必须套用的模板；应先遇重复结构、多处修改等信号再选用，避免过度设计。
为什么不该一上来就套用设计模式
设计模式不是API，也不是语法糖，它本质是“别人解决某类问题的思路总结”。直接照搬 Factory 或 Observer 往往导致过度设计：比如一个只有两个分支的 if 判断，硬套 Strategy 模式，反而让逻辑更难追踪。
真正该用设计模式的信号是——你开始反复复制相似结构、修改一处要改多处、或者新增一种行为要动到已有类的核心逻辑。这时再回头找匹配的模式，才自然。
工厂模式在对象创建场景中的实际取舍
当构造逻辑复杂（如需读配置、校验参数、组合多个依赖）或创建过程需要隔离变化（如不同环境用不同实现），SimpleFactory 或 AbstractFactory 才有价值。
-
SimpleFactory适合小范围解耦，但违反开闭原则——每加一种产品就要改工厂类 -
AbstractFactory适合产品族（如WindowsButton+WindowsDialog），但类数量爆炸，Java里常被 Spring 的@Bean+ 条件化注册替代 - 现代 Java 更倾向用
Supplier<t></t>或构建器（Builder）替代简单工厂，代码更轻、测试更直接
观察者模式与 Java 内置 API 的冲突点
Java 早期提供 java.util.Observable 和 Observer，但它是类继承方式，且线程不安全、通知顺序不可控。JDK 9 已标记为废弃。
立即学习“Java免费学习笔记（深入）”；
