设计模式对比（优缺点）
| 设计模式 | 适用场景 | 定义/特点 | 优点 | 缺点 |
|---|---|---|---|---|
| Simple factory | Static工厂方法 + switch case | Client无需知道具体类名，只用传入参数 | ❌Open-Close | |
| Factory | 每个产品都有自己的专属工厂（子类），工厂之间是平行的 | ✅Open-Close | 类数量爆炸 | |
| Abstract factory | 每个品牌（产品族）有自己的综合工厂，这个工厂能生产该品牌下的所有产品（如电视、空调、冰箱） | ✅Open-Close(增加产品族时) | ❌Open-Close(增加产品种类) | |
| Builder | 多个对象步骤相同 结果不同 | 流程固定，部件可变（对象有复杂结构） | ✅Open-Close，良好封装 | 产品共性要求高 |
| Prototype | 邮件复制 图形编辑器 游戏开发 配置系统对象 | 自我复制，适用于创建过程复杂、需要频繁实例化 | 良好扩展 | ❌Open-Close（修改现有类要改源码） |
| Singlton | 只需要或只允许建立一个obj：任务管理器 数据库连接池 打印池 | 确保一个类只有一个实例，并提供一个全局访问点 | 节约资源 | ❌Single Responsibility(职责过重)难以扩展(oc?) |
| Adapter | 电器协议不兼容 | 解决不兼容问题 | 提高Reuse，灵活和扩展性好 | Class adapter不能适配final |
| Bridge | 分离抽象与实现 | ✅Open-Close，减少子类数量 | 理解实现难 | |
| Composite | 树形结构 | 将对象组合成树形结构以表示”部分-整体”的层次结构 | ✅Open-Close | 设计复杂 |
| Decorate | 动态地给一个对象添加一些额外的职责 | ✅Open-Close | 大量小对象，使用困难 | |
| Facade | UI界面 | 分离Client和subsystem，UI | ✅Law of Demeter(最少知识) | 如果设计不当，❌Open-Close |
| Chain of R | 责任审批 | Client不需要知道handler | ✅Open-Close | 调试困难、性能问题 |
| Command | 餐厅点单系统，编辑器撤销功能 | 支持事物操作(排队 日志 撤销) | 低耦合，容易加入Command | 可能过多ConcreteCommand类 |
| Iterator | 需要遍历的场景 | 访问对象中的各个元素，而又不暴露该对象的内部表示 | ✅Open-Close | 复杂，可能过度设计 |
| Strategy | 在几个算法之间选择 | 在几个算法之间选择 | ✅Open-Close, Reuse | 用户要了解所有Strategy |