设计模式
一、23种设计模式
| 分类 | 模式名称 | 一句话定义 | 核心要点 | 典型应用场景 |
|---|---|---|---|---|
| 创建型(5种) | 单例Singleton | 保证一个类只有一个实例 | 私有构造、全局访问点 | 日志管理器、数据库连接池、配置对象 |
| 工厂方法Factory Method | 定义创建对象的接口，由子类决定实例化谁 | 类级别、依赖继承 | 日志记录器（文件/数据库）、支付渠道选择 | |
| 抽象工厂Abstract Factory | 创建一组相关或相互依赖的对象族 | 对象组合、拒绝多if-else | 跨平台UI组件（Win/Mac按钮和文本框） | |
| 建造者Builder | 分步构建复杂对象，分离构造与表示 | 链式调用、Director指挥 | SQL查询构造器、StringBuilder、复杂订单 | |
| 原型Prototype | 通过拷贝现有对象来创建新对象 | 实现Clone接口、浅/深拷贝 | 游戏怪物克隆、对象初始化成本高的场景 | |
| 结构型(7种) | 适配器Adapter | 将一个类的接口转换成客户端期望的接口 | 包装器、兼容旧代码 | 电源转接头、第三方SDK接口适配 |
| 桥接Bridge | 将抽象与实现分离，让它们独立变化 | 组合优于继承 | 消息发送（抽象：普通/紧急 vs 实现：邮件/SMS） | |
| 装饰器Decorator | 动态地给对象添加职责，比继承灵活 | 层层包裹、透明扩展 | Java I/O流 (BufferedInputStream) |
|
| 代理Proxy | 为对象提供一个代理以控制访问 | 中介、延迟加载 | 虚拟代理（图片懒加载）、权限代理 | |
| 外观Facade | 为复杂的子系统提供一个统一的简单接口 | 简化调用、降低耦合 | JDBC封装、启动电脑（一键开机） | |
| 享元Flyweight | 共享细粒度对象，减少内存消耗 | 池化技术、内部/外部状态 | 字符串常量池、围棋棋子（颜色共享） | |
| 组合Composite | 将对象组合成树形结构以表示”部分-整体” | 递归结构、一致对待 | 文件系统（文件夹与文件）、组织架构树 | |
| 行为型(11种) | 策略Strategy | 定义一系列算法，封装起来，让它们可互换 | 消除大量条件判断 | 电商促销策略（满减/折扣/返现）、排序算法 |
| 观察者Observer | 定义一对多的依赖，当一个对象改变时通知所有依赖者 | 发布-订阅机制 | 事件监听（Button点击事件）、RxJava | |
| 命令Command | 将请求封装成一个对象，支持撤销和排队 | 解耦请求者与执行者 | 菜单按钮操作、宏命令、线程池任务 | |
| 模板方法Template Method | 定义算法骨架，将某些步骤延迟到子类 | 钩子方法、代码复用 | 数据库访问流程（连接-执行-关闭）、JUnit | |
| 状态State | 允许对象在其内部状态改变时改变它的行为 | 用多态代替if-else | 订单状态流转（待支付/已发货/已完成）、电梯状态 | |
| 责任链Chain of Resp. | 将请求沿着处理链传递，直到被处理 | 解耦发送者和接收者 | 审批流、Servlet Filter、拦截器 | |
| 备忘录Memento | 在不破坏封装的前提下，捕获并恢复对象状态 | 快照机制 | 编辑器撤销(Ctrl+Z)、游戏存档 | |
| 中介者Mediator | 用一个中介对象封装一组对象的交互 | 减少对象间耦合 | 聊天室（通过服务器转发）、MVC的Controller | |
| 访问者Visitor | 将作用于某对象结构的操作分离出来封装 | 数据结构稳定，操作易变 | 编译器（AST节点遍历）、报表生成器 | |
| 迭代器Iterator | 提供一种方法顺序访问聚合对象中的元素 | 统一遍历接口 | Java Collection的 iterator()、for-each |
|
| 解释器Interpreter | 给定一个语言，定义其文法的一种表示，并解释执行 | 语法树解析 | 正则表达式引擎、SQL解析、数学表达式计算 |
二、MVX设计模式
| 模式 | 全称与核心组成 | 数据流与交互逻辑 | 优点 | 缺点 | 典型应用场景 |
|---|---|---|---|---|---|
| MVC | Model-View-Controller• M: 数据/业务• V: 界面展示• C: 接收输入，调度M/V | 双向混乱View常直接读Model，Controller同时操控View和Model。很多实现中V和C紧耦合（如iOS）。 | • 概念简单，易上手• 开发速度快（小项目） | • Controller臃肿（Massive VC）• View与Model耦合，难测试• 逻辑分散，维护困难 | • 早期Web开发（PHP/JSP）• iOS原生开发（Apple MVC）• 简单Demo或小型工具 |
| MVP | Model-View-Presenter• M: 数据/业务• V: 被动视图• P: 纯逻辑调度 | 单向清晰View <-> Presenter <-> Model。View只负责画UI，通过接口通知Presenter；Presenter持有View接口，更新UI。 | • 彻底解耦（V与M互不知晓）• Presenter无Android/iOS Context，极易单元测试• 逻辑集中，易于维护 | • Presenter易臃肿• 手动更新UI繁琐（需写大量setText等代码）• View接口可能过多 |
• 传统Android开发• WinForms/ASP.NET Web Forms• 需要高测试覆盖率的项目 |
| MVVM | Model-View-ViewModel• M: 数据/业务• V: 界面展示• VM: View的抽象模型 | 双向绑定View <-> (Binder) <-> ViewModel。View与ViewModel通过框架自动同步（Data Binding），无需手动调用。 | • 开发效率极高（消灭样板代码）• 数据驱动，代码简洁• 比MVP更解耦，测试性良好 | • 调试困难（数据流向不直观，难定位Bug）• 内存泄漏风险（绑定未释放）• 复杂逻辑导致ViewModel膨胀 | • 前端主流（Vue/React/Angular）• WPF/UWP• Android Jetpack (LiveData/DataBinding)• 数据密集型应用 |
| MVPVM | MVP + MVVM• M: 数据• V: 视图• P: 业务逻辑• VM: 数据包装 | 双轨制View <-> Presenter <-> ViewModel <-> Model。P负责逻辑，VM负责适配数据供V绑定。 | • 兼具MVP的强测试性和MVVM的高效率• 职责分离更彻底（P只管逻辑，VM只管数据） | • 架构复杂，学习成本高• 类数量翻倍，代码量较大• 小型项目杀鸡用牛刀 | • 大型桌面应用（WPF）• 复杂企业级移动应用• 需要严格分层的大型项目 |
| VIPER | View-Interactor-Presenter-Entity-Router• V: UI展示• I: 业务逻辑/用例• P: 格式化数据• E: 实体• R: 路由/导航 | 单向闭环View -> Presenter -> Interactor -> Entity。严格遵循Clean Architecture，每一层只做一件事。 | • 职责切分到极致• 极高的可测试性和模块化• 代码极其规范，适合团队协作 | • 类爆炸（一个页面5+文件）• 极度繁琐，开发效率低• 学习曲线非常陡峭 | • 超大型iOS/Android项目• 金融、银行类App（业务极其复杂）• 长期维护的核心产品 |