设计模式是解决问题的思路总结，而非必须套用的模板；应先遇重复结构、多处修改等信号再选用，避免过度设计。
为什么不该一上来就套用设计模式
设计模式不是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免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
现在更推荐：
- 用
java.beans.PropertyChangeListener处理 Bean 属性变更（注意仅限标准 JavaBean） - 自己写轻量级发布-订阅（如用
CopyOnWriteArrayList存 listeners，避免并发修改异常） - 响应式编程中直接用
Flow.Publisher/ReactiveStreams，比手写观察者更健壮
别为了“用模式”而绕过 Stream、CompletableFuture 这些原生异步工具。
装饰器模式在 IO 和 Spring AOP 中的真实边界
InputStream 体系是教科书级的装饰器：比如 BufferedInputStream 包一层 FileInputStream，既复用底层读取，又叠加缓冲能力。关键在于所有装饰器都实现同一接口，且构造时传入被装饰对象。
但 Spring AOP 不是装饰器模式——它用代理（JdkDynamicProxy 或 CGLIB）在运行时织入逻辑，目标对象甚至不知道自己被“装饰”了。二者语义不同：
- 装饰器是显式组合，调用链清晰可读
- AOP 是隐式拦截，调试时容易丢失上下文（比如
@Transactional失效常因代理未生效） - 想手动模拟 AOP 行为？别硬套装饰器，优先考虑
Filter链或函数式接口（Function<t r></t>）包装
模式只是描述，不是约束。Java 的泛型、lambda、模块系统正在让很多传统模式变得冗余——看清问题本质，比记住模式名字重要得多。
