设计模式学习资料（持续更新）

墨蓝 2022-10-07 14:59 292阅读 0赞

### 文章目录 ###

*  设计模式学习资料（持续更新）
 *   *  前言
     *  图书
     *  设计模式分类
     *  设计模式目录
     *  设计模式所支持的设计的可变方面
     *  什么时候需要用到设计模式
     *  面向对象设计（OOD）
     *   *  OOD基础
         *  OOD原则
     *  参考文档
 *  云设计模式

# 设计模式学习资料（持续更新） #

## 前言 ##

本文汇总了设计模式的一些常用资料，用于快速查找。

## 图书 ##

*  《设计模式 - 可复用面向对象软件的基础》
 *  《Head First - 设计模式》
 *  《Java设计模式及实践》

## 设计模式分类 ##

设计模式根据其目的分为：

*  创建型（creational patterns) - 与对象的创建有关
 *  结构型（structural patterns）- 处理类和对象的组合
 *  行为型（behavioral patterns) - 对类或对象怎样交互和怎样分配职责进行描述

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th><a href="https://refactoring.guru/design-patterns/creational-patterns" rel="nofollow">创建型(Creational Patterns)</a></th> 
   <th><a href="https://refactoring.guru/design-patterns/structural-patterns" rel="nofollow">结构型 (Structural Patterns)</a></th> 
   <th><a href="https://refactoring.guru/design-patterns/behavioral-patterns" rel="nofollow">行为型(Behavioral Patterns)</a></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>类</td> 
   <td><a href="https://refactoring.guru/design-patterns/factory-method" rel="nofollow">工厂方法(Factory Method) / Virtual Constructor</a></td> 
   <td><a href="https://refactoring.guru/design-patterns/adapter" rel="nofollow">适配器（Adapter）/ Wrapper</a></td> 
   <td>解释器（Interpreter）<br><a href="https://refactoring.guru/design-patterns/template-method" rel="nofollow">模板方法（Tempalte Method)</a></td> 
  </tr> 
  <tr> 
   <td>对象</td> 
   <td><a href="https://refactoring.guru/design-patterns/abstract-factory" rel="nofollow">抽象工厂(Abstract Factory)</a><br><a href="https://refactoring.guru/design-patterns/builder" rel="nofollow">构造器（Builder）</a><br><a href="https://refactoring.guru/design-patterns/prototype" rel="nofollow">原型(Prototype) / Clone</a> <br><a href="https://refactoring.guru/design-patterns/singleton" rel="nofollow">单例(Singleton)</a></td> 
   <td><a href="https://refactoring.guru/design-patterns/adapter" rel="nofollow">适配器（Adapter）/ Wrapper</a><br><a href="https://refactoring.guru/design-patterns/bridge" rel="nofollow">桥接(Bridge)</a><br><a href="https://refactoring.guru/design-patterns/composite" rel="nofollow">组合(Composite) / Object Tree</a><br><a href="https://refactoring.guru/design-patterns/decorator" rel="nofollow">装饰器（Decorator）/ Wrapper</a><br><a href="https://refactoring.guru/design-patterns/facade" rel="nofollow">门面（Facade）</a><br><a href="https://refactoring.guru/design-patterns/flyweight" rel="nofollow">蝇量（Flyweight）/ Cache</a><br><a href="https://refactoring.guru/design-patterns/proxy" rel="nofollow">代理（Proxy）</a></td> 
   <td><a href="https://refactoring.guru/design-patterns/chain-of-responsibility" rel="nofollow">责任链（Chain of Responsibility)</a><br><a href="https://refactoring.guru/design-patterns/command" rel="nofollow">命令(Command) / Action, Transaction </a><br><a href="https://refactoring.guru/design-patterns/iterator" rel="nofollow">迭代器（Iterator）</a><br><a href="https://refactoring.guru/design-patterns/mediator" rel="nofollow">中介（Mediator）</a><br><a href="https://refactoring.guru/design-patterns/memento" rel="nofollow">备忘录（Memento）/ Snapshot</a> <br><a href="https://refactoring.guru/design-patterns/observer" rel="nofollow">观察者(Observer)</a><br><a href="https://refactoring.guru/design-patterns/state" rel="nofollow">状态（State）</a><br><a href="https://refactoring.guru/design-patterns/strategy" rel="nofollow">策略（Strategy)</a><br><a href="https://refactoring.guru/design-patterns/visitor" rel="nofollow">访问者（Visitor)</a></td> 
  </tr> 
 </tbody> 
</table>

## 设计模式目录 ##

按照模式的字母排序。

<table> 
 <thead> 
  <tr> 
   <th>模式</th> 
   <th>描述</th> 
   <th>比喻</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/abstract-factory" rel="nofollow">Abstract Factory（抽象工厂）</a></td> 
   <td>提供一个创建一系列相关或相互依赖对象的接口，而无需制定它们具体的类。</td> 
   <td>家具城有几家不同风格的家具制造商，包括中式、欧式奢华风格、北欧简约风格 。每家家具制造商都生产餐桌、餐椅、床、茶几等一系列家具。顾客可以根据自己喜好选择购买哪家风格的家具制造商的系列家具。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/adapter" rel="nofollow">Adapter（适配器）</a></td> 
   <td>将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。</td> 
   <td>多功能转接头，连接到Mac笔记本电脑的Type-C口，可以支持转接USB、HDMI和LAN口。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/bridge" rel="nofollow">Bridge（桥接）</a></td> 
   <td>将抽象部分与它的实现部分分离，使他们都可以独立地变化。</td> 
   <td>手机通过蓝牙连接智能音箱，播放音乐。手机和音箱可以是不同品牌的。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/builder" rel="nofollow">Builder（构造器）</a></td> 
   <td>将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。</td> 
   <td>一台意式咖啡机，可以制作拿铁、摩卡、卡布奇诺、美式等多种口味的咖啡。因为可以将制作咖啡的过程分解为：制作意式浓缩咖啡、加糖浆、倒入咖啡杯、打奶泡、拉花等步骤。通过组合这些步骤就可以制作不同口味的咖啡。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/chain-of-responsibility" rel="nofollow">Chain of Responsibility（责任链）</a></td> 
   <td>解除请求的发送者和接收者之间的耦合，使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。</td> 
   <td>乘坐飞机的登机过程。换登机牌-办理行李托运-过安检-过登机口-坐摆渡车-进入飞机客舱。有任何一个环节出问题都不能顺利登机。每个环节都有检查/确认。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/command" rel="nofollow">Command（命令） </a></td> 
   <td>将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。</td> 
   <td>一家餐厅支持三种点餐方式：叫服务员来点餐、微信自助点餐和接受外卖网站的订单点餐。但是这几种点餐的信息都会先进入到餐厅的点餐系统，再通过在后厨的打印机打印点餐单，厨师根据点餐单来制作菜品。顾客-服务员-点餐单-厨师，这个例子中“点餐单”就是一个命令对象，厨师的命令接收者，服务员是命令调用者。顾客作为命令发起者，也可以撤销命令，比如取消某个还未开始制作的菜品。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/composite" rel="nofollow">Composite（组合）</a></td> 
   <td>将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得客户对单个对象和组合对象的使用具有一致性。</td> 
   <td>部队的层级一般为军、师、旅、团、营、连、排、班，其中班是部队最小单位。假设一个班有10名士兵，一个排有3个班，一个连有3个排，一个营有4个连，一个团有3个营等。这样就可以推出各个层级的大致人数。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/decorator" rel="nofollow">Decorator（装饰器）</a></td> 
   <td>动态地给一个对象添加一些额外的职责。就扩展功能而言，Decorator模式比生成子类方式更为灵活。</td> 
   <td>天冷时候出门，人们一般会穿有帽子的羽绒服、秋衣秋裤、围围巾、戴手套、穿厚的鞋子。每件衣服都有它独特的作用。并且每个人穿的可能也不一样，比如有人可能不围围巾，有人穿靴子。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/facade" rel="nofollow">Facade（门面）</a></td> 
   <td>为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。</td> 
   <td>客户与电信运营商打交道的主要渠道是营业厅、热线电话和微信公众号。但是一家电信运营商背后还有机房、线路、基站、设备、仓库、办公楼等，但是客户都看不到这些。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/factory-method" rel="nofollow">Factory Method（工厂方法）</a></td> 
   <td>定义一个用于创建对象的接口，让子类决定将哪一个类实例化。Factory Method使一个类的实例化延迟到其他子类。</td> 
   <td>粽子连锁店，在不同地方的工厂生产符合当地人口味的粽子。比如南方生产五花肉咸粽子、排骨咸粽子和咸鸭蛋咸粽子，北方生产红豆甜粽子、板栗甜粽子、红枣甜粽子。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/flyweight" rel="nofollow">Flyweight（蝇量）</a></td> 
   <td>运用共享技术有效地支持大量细粒度的对象。</td> 
   <td>大家往网盘上存储文件时，网盘承诺给每人100G存储空间。但是其实并不是给别人固定划分了100G存储空间，而是动态扩展的。除此之外，如果两个人存储相同的一个文件（通过文件cheksum来判断），实际上网盘只存储了一份该文件，两个人都通过引用来访问该文件。</td> 
  </tr> 
  <tr> 
   <td>Interpreter(解释器)</td> 
   <td>给定一个语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。</td> 
   <td>编译器、智能客服。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/iterator" rel="nofollow">Iterator（迭代器）</a></td> 
   <td>提供一种方法顺序访问一个聚合对象中的各个元素，而又不需要暴露该对象的内部表示。</td> 
   <td>故宫很大，想一天把主要景点都逛完有点难度。你可以根据景点的指示牌来逛。也可以根据故宫景点地图来逛。也可以雇一个导游来带着你逛。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/mediator" rel="nofollow">Mediator（中介）</a></td> 
   <td>用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。</td> 
   <td>租房客通过中介来和房东联系。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/memento" rel="nofollow">Memento（备忘录）</a></td> 
   <td>在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。</td> 
   <td>虚拟机快照，数据备份。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/observer" rel="nofollow">Observer（观察者）</a></td> 
   <td>定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动刷新。</td> 
   <td>服务注册中心，有服务提供者掉线后，服务调用者会得到通知并自动刷新，不会再将新的请求发送给该掉线的服务提供者。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/prototype" rel="nofollow">Prototype（原型）</a></td> 
   <td>用原型实例制定创建对象的种类，并且通过拷贝这个原型来创建新的对象。</td> 
   <td>克隆代码仓库、克隆虚拟机、克隆光盘。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/proxy" rel="nofollow">Proxy（代理）</a></td> 
   <td>为其他对象提供一个代理以控制对这个对象的访问。</td> 
   <td>一般，你不会直接去汽车制造厂买车，而是选择当地一个汽车经销商（4S店）来购买汽车。<br>电视节目邀请明星参加，一般不会直接联系该明星，可以先联系明星的经纪人。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/singleton" rel="nofollow">Singleton（单例）</a></td> 
   <td>保证一个类仅有一个实例，并提供一个访问它的全局访问点。</td> 
   <td>一个国家只有一个政府。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/state" rel="nofollow">State（状态）</a></td> 
   <td>允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。</td> 
   <td>状态机。手机锁屏后，按下任何按钮，都会到解锁界面。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/strategy" rel="nofollow">Strategy（策略）</a></td> 
   <td>定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。</td> 
   <td>从家去机场坐飞机，可以选择机场大巴、地铁、滴滴或的士。 <br> 网上购物时，可以选择微信支付、支付宝支付或信用卡支付等。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/template-method" rel="nofollow">Tempalte Method（模板方法）</a></td> 
   <td>定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Tempalte Method使得子类不改变一个算法的结构即可重定义该算法的某些特定步骤。</td> 
   <td>餐厅的商务午餐套餐，包括主食、肉、菜、饮料/汤各1份，客户可以根据自己的喜好选择。</td> 
  </tr> 
  <tr> 
   <td><a href="https://refactoring.guru/design-patterns/visitor" rel="nofollow">Visitor（访问者）</a></td> 
   <td>表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。</td> 
   <td>在碑林博物馆的的每块石碑附近粘贴语音解说二维码。游客可以扫码来听关于该石碑的语音解说。</td> 
  </tr> 
 </tbody> 
</table>

## 设计模式所支持的设计的可变方面 ##

可以根据设计模式所支持的设计的可变方面（关注点）来选择合适的设计模式。

<table> 
 <thead> 
  <tr> 
   <th>目的</th> 
   <th>设计模式</th> 
   <th>可变的方面</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>创建</td> 
   <td><a href="https://refactoring.guru/design-patterns/abstract-factory" rel="nofollow">Abstract Factory（抽象工厂）</a></td> 
   <td>产品对象家族</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td><a href="https://refactoring.guru/design-patterns/builder" rel="nofollow">Builder（构造器）</a></td> 
   <td>如何创建一个组合对象</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td><a href="https://refactoring.guru/design-patterns/factory-method" rel="nofollow">Factory Method（工厂方法）</a></td> 
   <td>被实例化的子类</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td><a href="https://refactoring.guru/design-patterns/prototype" rel="nofollow">Prototype（原型）</a></td> 
   <td>被实例化的类</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td><a href="https://refactoring.guru/design-patterns/singleton" rel="nofollow">Singleton（单例）</a></td> 
   <td>一个类的唯一实例</td> 
  </tr> 
  <tr> 
   <td>结构</td> 
   <td><a href="https://refactoring.guru/design-patterns/adapter" rel="nofollow">Adapter（适配器）</a></td> 
   <td>对象的接口</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td><a href="https://refactoring.guru/design-patterns/bridge" rel="nofollow">Bridge（桥接）</a></td> 
   <td>对象的实现</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td><a href="https://refactoring.guru/design-patterns/composite" rel="nofollow">Composite（组合）</a></td> 
   <td>一个对象的结构和组成</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td><a href="https://refactoring.guru/design-patterns/decorator" rel="nofollow">Decorator（装饰器）</a></td> 
   <td>对象的职责，不生成子类</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td><a href="https://refactoring.guru/design-patterns/facade" rel="nofollow">Facade（门面）</a></td> 
   <td>一个子系统的接口</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td><a href="https://refactoring.guru/design-patterns/flyweight" rel="nofollow">Flyweight（蝇量）</a></td> 
   <td>对象的存储开销</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td><a href="https://refactoring.guru/design-patterns/proxy" rel="nofollow">Proxy（代理）</a></td> 
   <td>如何访问一个对象；该对象的位置</td> 
  </tr> 
  <tr> 
   <td>行为</td> 
   <td><a href="https://refactoring.guru/design-patterns/chain-of-responsibility" rel="nofollow">Chain of Responsibility（责任链）</a></td> 
   <td>满足一个请求的对象</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td><a href="https://refactoring.guru/design-patterns/command" rel="nofollow">Command（命令） </a></td> 
   <td>何时，怎样满足一个请求</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td>Interpreter(解释器)</td> 
   <td>一个语言的文法及解释</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td><a href="https://refactoring.guru/design-patterns/iterator" rel="nofollow">Iterator（迭代器）</a></td> 
   <td>如何遍历、访问一个聚合的各个元素</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td><a href="https://refactoring.guru/design-patterns/mediator" rel="nofollow">Mediator（中介）</a></td> 
   <td>对象如何交互、和谁交互</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td><a href="https://refactoring.guru/design-patterns/memento" rel="nofollow">Memento（备忘录）</a></td> 
   <td>一个对象中哪些私有信息存放在该对象之外，以及在什么时候进行存储</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td><a href="https://refactoring.guru/design-patterns/observer" rel="nofollow">Observer（观察者）</a></td> 
   <td>多个对象依赖于另外一个对象，而这些对象又如何保持一致</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td><a href="https://refactoring.guru/design-patterns/state" rel="nofollow">State（状态）</a></td> 
   <td>对象的状态</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td><a href="https://refactoring.guru/design-patterns/strategy" rel="nofollow">Strategy（策略）</a></td> 
   <td>算法</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td><a href="https://refactoring.guru/design-patterns/template-method" rel="nofollow">Tempalte Method（模板方法）</a></td> 
   <td>算法的某些步骤</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td><a href="https://refactoring.guru/design-patterns/visitor" rel="nofollow">Visitor（访问者）</a></td> 
   <td>某些可作用于一个（组）对象上的操作，但不修改这些对象的类</td> 
  </tr> 
 </tbody> 
</table>

## 什么时候需要用到设计模式 ##

出现以下Code Smells的时候可以考虑使用设计模式：

*  大量重复或类似的代码
 *  大量的`if-else`语句
 *  `{}`嵌套很多层
 *  一个方法中塞入了太多行代码
 *  难以对现有代码进行重构
 *  代码难以测试
 *  某个类经常出现代码合并冲突

## 面向对象设计（OOD） ##

### OOD基础 ###

OOD基础概念包括：

*  抽象
 *  封装
 *  多态
 *  继承

### OOD原则 ###

OOD原则包括：

*  优先使用对象组合，而不是类继承继承
 *  针对接口编程（interface或abstract class），而不是针对实现编程
 *  为交互对象之间的松耦合设计而努力
 *  类应对扩展开放，对修改关闭
 *  依赖抽象，不要依赖具体类

## 参考文档 ##

*  [https://refactoring.guru/design-patterns/][https_refactoring.guru_design-patterns] 对每种设计模式进行了详细的描述，包括模式的意图、要解决的问题和举例、解决方案、结构、伪代码、适用性、如何实现模式、优点和缺点、与其他模式的关系和多种编程语言的代码示例。

# 云设计模式 #

*  [微软 - 云设计模式][-]
 *  [Microsoft - Cloud Design Patterns][]

[https_refactoring.guru_design-patterns]: https://refactoring.guru/design-patterns/
[-]: https://docs.microsoft.com/zh-cn/azure/architecture/patterns/
[Microsoft - Cloud Design Patterns]: https://docs.microsoft.com/en-us/azure/architecture/patterns/