| 分类 | 设计模式 | 简述 | 一句话归纳 | 目的 | 生活案例 |
| 创建型设计模式 （简单来说就是用来创建对象的） | 工厂模式（Factory Pattern） | 不同条件下创建不同实例 | 产品标准化，生产更高效 | 封装创建细节 | 实体工厂 |
| ^ | 单例模式（Singleton Pattern） | 保证一个类仅有一个实例，并且提供一个全局访问点 | 世上只有一个我 | 保证独一无二 | CEO |
| ^ | 原型模式（Prototype Pattern） | 通过拷贝原型创建新的对象 | 拔一根猴毛，吹出千万个 | 高效创建对象 | 克隆 |
| ^ | 建造者模式（Builder Pattern） | 用来创建复杂的复合对象 | 高配中配和低配，想选哪配就哪配 | 开放个性配置步骤 | 选配 |
| 结构型设计模式 （关注类和对象的组合） | 代理模式（Proxy Pattern） | 为其他对象提供一种代理以控制对这个对象的访问 | 没有资源没时间，得找别人来帮忙 | 增强职责 | 媒婆 |
| ^ | 外观模式（Facade Pattern） | 对外提供一个统一的接口用来访问子系统 | 打开一扇门，通向全世界 | 统一访问入口 | 前台 |
| ^ | 装饰器模式（Decorator Pattern） | 为对象添加新功能 | 他大舅他二舅都是他舅 | 灵活扩展、同宗同源 | 煎饼 |
| ^ | 享元模式（Flyweight Pattern） | 使用对象池来减少重复对象的创建 | 优化资源配置，减少重复浪费 | 共享资源池 | 全国社保联网 |
| ^ | 组合模式（Composite Pattern） | 将整体与局部（树形结构）进行递归组合，让客户端能够以一种的方式对其进行处理 | 人在一起叫团伙，心在一起叫团队 | 统一整体和个体 | 组织架构树 |
| ^ | 适配器模式（Adapter Pattern） | 将原来不兼容的两个类融合在一起 | 万能充电器 | 兼容转换 | 电源适配 |
| ^ | 桥接模式（Bridge Pattern） | 将两个能够独立变化的部分分离开来 | 约定优于配置 | 不允许用继承 | 桥 |
| 行为型设计模式 （关注对象之间的通信） | 模板模式（Template Pattern） | 定义一套流程模板，根据需要实现模板中的操作 | 流程全部标准化，需要微调请覆盖 | 逻辑复用 | 把大象装进冰箱 |
| ^ | 策略模式（Strategy Pattern） | 封装不同的算法，算法之间能互相替换 | 条条大道通罗马，具体哪条你来定 | 把选择权交给用户 | 选择支付方式 |
| ^ | 责任链模式（Chain of Responsibility Pattern） | 拦截的类都实现统一接口，每个接收者都包含对下一个接收者的引用。将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。 | 各人自扫门前雪，莫管他们瓦上霜 | 解耦处理逻辑 | 踢皮球 |
| ^ | 迭代器模式（Iterator Pattern） | 提供一种方法顺序访问一个聚合对象中的各个元素 | 流水线上坐一天，每个包裹扫一遍 | 统一对集合的访问方式 | 逐个检票进站 |
| ^ | 命令模式（Command Pattern） | 将请求封装成命令，并记录下来，能够撤销与重做 | 运筹帷幄之中，决胜千里之外 | 解耦请求和处理 | 遥控器 |
| ^ | 状态模式（State Pattern） | 根据不同的状态做出不同的行为 | 状态驱动行为，行为决定状态 | 绑定状态和行为 | 订单状态跟踪 |
| ^ | 备忘录模式（Memento Pattern） | 保存对象的状态，在需要时进行恢复 | 失足不成千古恨，想重来时就重来 | 备份、后悔机制 | 草稿箱 |
| ^ | 中介者模式（Mediator Pattern） | 将对象之间的通信关联关系封装到一个中介类中单独处理，从而使其耦合松散 | 联系方式我给你，怎么搞定我不管 | 统一管理网状资源 | 朋友圈 |
| ^ | 解释器模式（Interpreter Pattern） | 给定一个语言，定义它的语法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子 | 我想说”方言“，一切解释权都归我 | 实现特定语法解析 | 摩斯密码 |
| ^ | 观察者模式（Observer Pattern） | 状态发生改变时通知观察者，一对多的关系 | 到点就通知我 | 解耦观察者与被观察者 | 闹钟 |
| ^ | 访问者模式（Visitor Pattern） | 稳定数据结构，定义新的操作行为 | 横看成岭侧成峰，远近高低各不同 | 解耦数据结构和数据操作 | KPI考核 |
| ——— | 委派模式（Delegate Pattern） | 允许对象组合实现与继承相同的代码重用，负责任务的调用和分配 | 这个需求很简单，怎么实现我不管 | 只对结果负责 | 授权委托书 |
| 设计原则 | 一句话归纳 | 目的 |
|---|---|---|
| 开闭原则 | 对扩展开放，对修改关闭 | 降低维护带来的新风险 |
| 依赖倒置原则 | 高层不应该依赖低层，要面向接口编程 | 更利于代码结构的升级扩展 |
| 单一职责原则 | 一个类只干一件事，实现类要单一 | 便于理解，提高代码的可读性 |
| 接口隔离原则 | 一个接口只干一件事，接口要精简单一 | 功能解耦，高聚合、低耦合 |
| 迪米特法则 | 不该知道的不要知道，一个类应该保持对其它对象最少的了解，降低耦合度 | 只和朋友交流，不和陌生人说话，减少代码臃肿 |
| 里氏替换原则 | 不要破坏继承体系，子类重写方法功能发生改变，不应该影响父类方法的含义 | 防止继承泛滥 |
| 合成复用原则 | 尽量使用组合或者聚合关系实现代码复用，少使用继承 | 降低代码耦合 |