178

docs: typo onDropOver

001.精读 js 模块化发展.md

@@ -103,7 +103,7 @@ YUI3 的 sandbox 像极了差不多同时出现的 AMD 规范，但早期 yahoo
 
 > 看到大家基本都提到了 HTTP/2，对这项技术解决前端模块化及资源打包等工程问题抱有非常大的期待。很多人也认为 HTTP/2 普及后，基本就没有 Webpack 什么事情了。
 
-不过 Webpack 作者 @sokra 在他的文章 [webpack & HTTP/2](https://medium.com/webpack/webpack-http-2-7083ec3f3ce6#.zdo4juvgo) 里提到了一个新的 Webpack 插件 `AggressiveSplittingPlugin`。简单的说，这款插件就是为了充分利用 HTTP/2 的文件缓存能力，将你的业务代码自动拆分成若干个数十 KB 的小文件。后续若其中任意一个文件发生变化，可以保证其他的小 chunck 不需要重新下载。
+不过 Webpack 作者 @sokra 在他的文章 [webpack & HTTP/2](https://medium.com/webpack/webpack-http-2-7083ec3f3ce6#.zdo4juvgo) 里提到了一个新的 Webpack 插件 `AggressiveSplittingPlugin`。简单的说，这款插件就是为了充分利用 HTTP/2 的文件缓存能力，将你的业务代码自动拆分成若干个数十 KB 的小文件。后续若其中任意一个文件发生变化，可以保证其他的小 chunk 不需要重新下载。
 
 可见，**即使不断的有新技术出现，也依然需要配套的工具来将前端工程问题解决方案推向极致。**
 

003.精读前后端渲染之争.md

@@ -27,7 +27,7 @@
 
 - 服务端渲染不需要先下载一堆 js 和 css 后才能看到页面（首屏性能）
 - SEO
-- 服务端渲染不用关心浏览器兼容性问题（随意浏览器发展，这个优点逐渐消失）
+- 服务端渲染不用关心浏览器兼容性问题（随着浏览器发展，这个优点逐渐消失）
 - 对于电量不给力的手机或平板，减少在客户端的电量消耗很重要
 
 以上服务端优势其实只有首屏性能和 SEO 两点比较突出。但现在这两点也慢慢变得微不足道了。React 这类支持同构的框架已经能解决这个问题，尤其是 Next.js 让同构开发变得非常容易。还有静态站点的渲染，但这类应用本身复杂度低，很多前端框架已经能完全囊括。
@@ -142,4 +142,4 @@ Next.js 是时下非常流行的基于 React 的同构开发框架。作者之
 
 > 讨论地址是：[前后端渲染之争 · Issue #5 · dt-fe/weekly](http://link.zhihu.com/?target=https%3A//github.com/dt-fe/weekly/issues/5)
 
-> 如果你想参与讨论，请[点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，每周五发布。
+> 如果你想参与讨论，请[点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，每周五发布。

079.精读《React Hooks》.md

@@ -276,7 +276,7 @@ Hook 函数必须以 "use" 命名开头，因为这样才方便 eslint 做检查
 
 为什么不能用 condition 包裹 useHook 语句，详情可以见 [官方文档](https://reactjs.org/docs/hooks-rules.html#explanation)，这里简单介绍一下。
 
-React Hooks 并不是通过 Proxy 或者 getters 实现的（具体可以看这篇文章 [React hooks: not magic, just arrays](https://medium.com/@ryardley/react-hooks-not-magic-just-arrays-cd4f1857236e)），而是通过数组实现的，每次 `useState` 都会改变下标，如果 `useState` 被包裹在 condition 中，那每次执行的下标就可能对不上，导致 `useState` 导出的 `setter` 更新错数据。
+React Hooks 并不是通过 Proxy 或者 getters 实现的（具体可以看这篇文章 [React hooks: not magic, just arrays](https://medium.com/@ryardley/react-hooks-not-magic-just-arrays-cd4f1857236e)），而是通过链表实现的，每次 `useState` 都会改变下标，如果 `useState` 被包裹在 condition 中，那每次执行的下标就可能对不上，导致 `useState` 导出的 `setter` 更新错数据。
 
 虽然有 [eslint-plugin-react-hooks](https://www.npmjs.com/package/eslint-plugin-react-hooks) 插件保驾护航，但这第一次将 “约定优先” 理念引入了 React 框架中，带来了前所未有的**代码命名和顺序限制**（函数命名遭到官方限制，JS 自由主义者也许会暴跳如雷），但带来的便利也是前所未有的（没有比 React Hooks 更好的状态共享方案了，约定带来提效，自由的代价就是回到 renderProps or HOC，各团队可以自行评估）。
 

080.精读《怎么用 React Hooks 造轮子》.md

@@ -1,6 +1,6 @@
 ## 1 引言
 
-上周的 [精读《React Hooks》](https://github.com/dt-fe/weekly/blob/master/79.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20Hooks%E3%80%8B.md) 已经实现了对 React Hooks 的基本认知，也许你也看了 React Hooks 基本实现剖析（就是数组），但理解实现原理就可以用好了吗？学的是知识，而用的是技能，看别人的用法就像刷抖音一样（哇，饭还可以这样吃？），你总会有新的收获。
+上周的 [精读《React Hooks》](https://github.com/dt-fe/weekly/blob/master/79.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20Hooks%E3%80%8B.md) 已经实现了对 React Hooks 的基本认知，也许你也看了 React Hooks 基本实现剖析（单向链表），但理解实现原理就可以用好了吗？学的是知识，而用的是技能，看别人的用法就像刷抖音一样（哇，饭还可以这样吃？），你总会有新的收获。
 
 这篇文章将这些知识实践起来，看看广大程序劳动人民是如何发掘 React Hooks 的潜力的（造什么轮子）。
 

140.精读《结合 React 使用原生 Drag Drop API》.md

@@ -179,7 +179,7 @@ const dragProps = {
 
 ```jsx
 const dropProps = {
-  onDropOver: ev => {
+  onDragOver: ev => {
     // 做一些样式处理，提示用户此时松手会将元素防止在何处
   },
   onDrop: ev => {

163.精读《Spring 概念》.md

@@ -1,4 +1,4 @@
-[spring](https://spring.io/) 是 Java 非常重要的框架，且蕴含了一系列设计模式，非常值得研究，本期就通过 [Spring学习](https://www.cnblogs.com/wmyskxz/p/8820371.html) 这篇文章了解一下 spring。
+[spring](https://spring.io/) 是 Java 非常重要的框架，且蕴含了一系列设计模式，非常值得研究，本期就通过 [Spring 学习](https://www.cnblogs.com/wmyskxz/p/8820371.html) 这篇文章了解一下 spring。
 
 ## spring 为何长寿
 

165.精读《数据搭建引擎 bi-designer API-组件》.md

@@ -1076,7 +1076,6 @@ const componentMeta: Interfaces.ComponentMeta = {
 
 - 配置 fixTop 后即可吸顶，不需要组件做额外支持。
 - 如果置顶的组件具有筛选功能，吸顶后仍具有筛选功能。
--
 
 ### 组件内吸顶
 

167.精读《设计模式 - Abstract Factory 抽象工厂》.md

@@ -0,0 +1,115 @@
+# Abstract Factory（抽象工厂）
+
+Abstract Factory（抽象工厂）属于创建型模式，工厂类模式抽象程度从低到高分为：简单工厂模式 -> 工厂模式 -> 抽象工厂模式。
+
+**意图：提供一个接口以创建一系列相关或相互依赖的对象，而无须指定它们具体的类。**
+
+## 举例子
+
+如果看不懂上面的意图介绍，没有关系，设计模式需要在日常工作里用起来，结合例子可以加深你的理解，下面我准备了三个例子，让你体会什么场景下会用到这种设计模式。
+
+### 汽车工厂
+
+我们都知道汽车有很多零部件，随着工业革命带来的分工，很多零件都可以被轻松替换。但实际生活中我们消费者不愿意这样，我们希望买来的宝马车所包含的零部件都是同一系列的，以保证最大的匹配度，从而带来更好的性能与舒适度。
+
+所以消费者不愿意到轮胎工厂、方向盘工厂、车窗工厂去一个个采购，而是将需求提给了宝马工厂这家抽象工厂，由这家工厂负责组装。那你是这家工厂的老板，已知汽车的组成部件是固定的，只是不同配件有不同的型号，分别来自不同的制造厂商，你需要推出几款不同组合的车型来满足不同价位的消费者，你会怎么设计？
+
+### 迷宫游戏
+
+你做一款迷宫游戏，已知元素有房间、门、墙，他们之间的组合关系是固定的，你通过一套算法生成随机迷宫，这套算法调用房间、门、墙的工厂生成对应的实例。但随着新资料片的放出，你需要生成具有新功能的房间（可以回复体力）、新功能的门（需要魔法钥匙才能打开）、新功能的墙（可以被炸弹破坏），但修改已有的迷宫生成算法违背了开闭原则（需要在已有对象进行修改），如果你希望生成迷宫的算法完全不感知新材料的存在，你会怎么设计？
+
+### 事件联动
+
+假设我们做一个前端搭建引擎，现在希望做一套关联机制，以实现点击表格组件单元格，可以弹出一个模态框，内部展示一个折线图。已知业务方存在定制表格组件、模态框组件、折线图组件的需求，但组件之间联动关系是确定的，你会怎么设计？
+
+## 意图解释
+
+在汽车工厂的例子中，我们已知车子的构成部件，**为了组装成一辆车子，需要以一定方式拼装部件，而具体用什么部件是需要可拓展的**。
+
+在迷宫游戏的例子中，我们已知迷宫的组成部分是房间、门、墙，**为了生成一个迷宫，需要以某种算法生成许多房间、门、墙的实例，而具体用哪种房间、哪种门、哪种墙是这个算法不关心的，是需要可被拓展的**。
+
+在事件联动的例子中，我们已知这个表格弹出趋势图的交互场景基本组成元素是表格组件、模态框组件、折线图组件，**需要以某种联动机制让这三者间产生联动关系，而具体是什么表格、什么模态框组件、什么折线图组件是这个事件联动所不关心的，是需要可以被拓展的**，表格可以被替换为任意业务方注册的表格，只要满足点击 `onClick` 机制就可以。
+
+> **意图：提供一个接口以创建一系列相关或相互依赖的对象，而无须指定它们具体的类。**
+
+这三个例子不正是符合上面的意图吗？我们要设计的抽象工厂就是要 **创建一系列相关或相互依赖的对象**，在上面的例子中分别是汽车的组成配件、迷宫游戏的素材、事件联动的组件。**而无须指定它们具体的类**，也就说明了我们不关心车子方向盘用的是什么牌子，迷宫的房间是不是普通房间，联动机制的折线图是不是用 `Echarts` 画的，我们只要描述好他们之间的关系即可，**这带来的好处是，未来我们拓展新的方向盘、新的房间、新的折线图时，不需要修改抽象工厂。**
+
+## 结构图
+
+<img width=800 src="https://img.alicdn.com/tfs/TB1k8DVVkT2gK0jSZFkXXcIQFXa-1472-658.png">
+
+`AbstractFactory` 就是我们要的抽象工厂，描述了创建产品的抽象关系，比如描述迷宫如何生成，表格和趋势图怎么联动。
+
+至于具体用什么方向盘、用什么房间，是由 `ConcreteFactory` 实现的，所以我们可能有多个 `ConcreteFactory`，比如 `ConcreteFactory1` 实例化的墙壁是普通墙壁，`ConcreteFactory2` 实例化的墙壁是魔法墙壁，但其对 `AbstractFactory` 的接口是一致的，所以 `AbstractFactory` 不需要关心具体调用的是哪一个工厂。
+
+`AbstractProduct` 是产品抽象类，描述了比如方向盘、墙壁、折线图的创建方法，而 `ConcreteProduct` 是具体实现产品的方法，比如 `ConcreteProduct1` 创建的表格是用 `canvas` 画的，折线图是用 `G2` 画的，而 `ConcreteProduct2` 创建的表格是用 `div` 画的，折线图是用 `Echarts` 画的。
+
+这样，当我们要拓展一个用 `Rcharts` 画的折线图，用 `svg` 画的表格，用 `div` 画的模态框组成的事件机制时，只需要再创建一个 `ConcreteFactory3` 做相应的实现即可，再将这个 `ConcreteFactory3` 传递给 `AbstractFactory`，并不需要修改 `AbstractFactory` 方法本身。
+
+## 代码例子
+
+下面例子使用 javascript 编写。
+
+```typescript
+class AbstractFactory {
+  createProducts(concreteFactory: ConcreteFactory) {
+    const productA = concreteFactory.createProductA();
+    const productB = concreteFactory.createProductB();
+
+    // 建立 A 与 B 固定的关联，即便 A 与 B 实现换成任意实现都不受影响
+    productA.bind(productB);
+  }
+}
+```
+
+`productA.bind(productB)` 是一种抽象表示：
+
+- 对于汽车工厂的例子，表示组装汽车的过程。
+- 对于迷宫游戏的例子，表示生成迷宫的过程。
+- 对于事件联动的例子，表示创建组件间关联的过程。
+
+假设我们的迷宫有两套素材，分别是普通素材与魔法素材，只要在分别创建普通素材工厂 `ConcreteFactoryA`，与魔法素材工厂 `ConcreteFactoryB`，调用 `createProducts` 时传入的是普通素材，则产出的就是普通素材搭建的迷宫，传入的是魔法素材，则产出的就是用魔法素材搭建的迷宫。
+
+当我们要创建一套新迷宫材料，比如熔岩迷宫，我们只要创建一套熔岩素材（熔岩房间、熔岩门、熔岩墙壁），再组装一个 `ConcreteFactoryC` 熔岩素材生成工厂传递给 `AbstractFactory.createProducts` 即可。
+
+我们可以发现，使用抽象工厂模式，我们可以轻松拓展新的素材，比如拓展一套新的汽车配件，拓展一套新的迷宫素材，拓展一套新的事件联动组件，**这个过程只需要新建类即可，不需要修改任何类，符合开闭原则**。
+
+## 弊端
+
+任何设计模式都有其适用场景，反过来也说明了在某些场景下不适用。
+
+还是上面的例子，如果我们的需求不是拓展一个新轮子、新墙壁、新折线图，而是：
+
+- 汽车工厂要给汽车加一个新部件：自动驾驶系统。
+- 迷宫游戏要新增一个功能素材：陷阱。
+- 事件联动要新增一个联动对象：明细趋势统计表格。
+
+你看，这种情况不是为已有元素新增一套实现，而是实现一些新元素，就会非常复杂，因为我们不仅要为所有 `ConcreteFactory` 新增每一个元素，还要修改抽象工厂，以将新元素与旧元素间建立联系，违背了开闭原则。
+
+因此，对于已有元素固定的系统，适合使用抽象工厂，反之不然。
+
+## 总结
+
+抽象工厂对新增已有产品的实现适用，对新增一个产品种类不适用，可以参考结合了例子的下图加深理解：
+
+<img width=800 src="https://img.alicdn.com/tfs/TB1Fbn7Vlr0gK0jSZFnXXbRRXXa-1416-852.png">
+
+拓展一个熔岩素材包是 **增加一种产品风格**，适合使用抽象工厂设计模式；拓展一个陷阱是 **增加一个产品种类**，不适合使用抽象工厂设计模式。为什么呢？看下图：
+
+<img width=800 src="https://img.alicdn.com/tfs/TB12fL8VeL2gK0jSZFmXXc7iXXa-1696-640.png">
+
+创建迷宫这个抽象工厂做的事情，**是把已有的房间、门、墙壁建立关联**，因为操作的是抽象类，所以拓展一套具体实现（熔岩素材包）对这个抽象工厂没有感知，这样做很容易。
+
+但如果新增一个产品种类 - 陷阱，可以看到，抽象工厂必须将陷阱与前三者重新建立关联，这就要修改抽象工厂，不符合开闭原则。同时，如果我们已有素材包 1 ～素材包 999，就需要同时增加 999 个对应的陷阱实现（普通陷阱、魔法陷阱、熔岩陷阱），其工作量会非常大。
+
+因此，只有产品种类稳定时，需要频繁拓展产品风格时才适合用抽象工厂设计模式。
+
+> 讨论地址是：[精读《设计模式 - Abstract Factory 抽象工厂》· Issue #271 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/271)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

168.精读《设计模式 - Builder 生成器》.md

@@ -0,0 +1,147 @@
+# Builder（生成器）
+
+Builder（生成器）属于创建型模式，针对的是单个复杂对象的创建。
+
+**意图：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。**
+
+## 举例子
+
+如果看不懂上面的意图介绍，没有关系，设计模式需要在日常工作里用起来，结合例子可以加深你的理解，下面我准备了三个例子，让你体会什么场景下会用到这种设计模式。
+
+### 搭乐高积木
+
+乐高积木是很典型的随机拼装场景，你有很多乐高积木，要搭一个小房子都太复杂了，可能不得不看着说明书一步步操作，这就像创建一个复杂的对象，要传入非常多的参数，而且顺序还不能错。
+
+如果不考虑拼装乐高过程中的乐趣，你只是想快速得到一个标准的房子，怎么样才可以最快最省事？
+
+### 工厂流水线
+
+制作一个罐头要经历许多步骤，而其中一些步骤比如制作罐头是通用的，可以用这个罐头装很多东西，比如红枣罐头、黄桃罐头，那工厂流水线是怎么做到灵活可拓展的呢？
+
+### 创建数据库连接池
+
+建立一个数据库连接池，我们需要传入数据库的地址、用户名与密码、还有要创建多少大小的连接池，缓存的位置等等。
+
+考虑到数据库必须正确连接后才有效，创建时必须校验传入的数据库地址与密码的正确性，甚至存储方式与数据库类型还有关系，这是一个简单的 `new` 实例化可以解决的吗？
+
+## 意图解释
+
+在乐高积木的例子中，我们为了得到一个房子其实不需要关心每一个积木应该如何摆放，**我们只要交给组装工厂（一个人或者一个程序）产出标准房子就行了**，这其中参数可能是 `.setHouseType().build()` 设置房屋类型，而不需要 `new House(block1, block2, ... block999)` 传递这些没必要的参数。**其中组装工厂就是生成器**。
+
+在工厂流水线的例子中，**流水线就是生成器，一个流水线可以不通过不同组合生成不同作用的工厂**，黄桃罐头的流水线可以理解为 `new Builder().组装罐头().放入黄桃().build()`，红枣罐头的流水线可以理解为 `new Builder().组装罐头().放入红枣().build()`，我们可以复用生成器最基础的函数 `组装罐头()` 将其用于创建不同的产品中，复用了组装基础能力。
+
+在创建数据库例子中，我们可以先设置一些必要的参数再创建，比如 `new Builder().setUrl().setPassword().setType().build()`，这样在最终执行 `build` 函数的时候，可以对参数中存在关联的进行校验，而得到的对象也无法再被修改，这样比直接暴露数据库连接池对象，再一个值一个值 Set 多了如下好处：
+
+1. 对象无法被修改，保护了程序稳定性，减少了维护复杂度。
+2. 可以对参数关联进行一次性校验。
+3. 在创建对象之前不会存在中间态，即创建了对象实例，但缺少部分参数，这可能导致对象无法正确 work。
+
+**意图：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。**
+
+我们再理解一次意图，所谓构建与表示分离，就是指一个对象 `Person` 并不是简单的 `new Person()` 就可以实例化出来的，如果可以，那就是构建与表示一体。**所谓构建与表示分离，就是指 `Person` 只能描述，而不能通过 `new Person()` 实例化，将实例化工作通过 Builder 实现，这样同样一个构建过程可以创建不同的 `Person` 实例。**
+
+在乐高积木的例子中，通过乐高创建的房子并不是 `new House()` 出来，而是将构建与表示分离了，工厂流水线中我们创建一个黄桃罐头，不是通过 `new 黄桃罐头()`，而是通过流水线不同拼装方式来完成，在数据库例子中，我们没有通过 `new DB()` 的方式创建数据库，而是通过 Builder 来创建，这都体现了构建与表示的分离。
+
+## 结构图
+
+<img width=800 src="https://img.alicdn.com/tfs/TB14lOwYXT7gK0jSZFpXXaTkpXa-1382-466.png">
+
+- `Director` 指导器，用来指导构建过程。
+- `Builder` 生成器接口，用来提供一系列构建对象的方法，以及最终的 `build` 生成对象函数，这个函数里可以做一些参数校验。
+- `ConcreteBuilder` 是 `Builder` 的具体实现。
+
+实际上，Builder 模式抽象层次可高可低，我们上面三个例子都没有用到指导器与生成器接口，这是因为在代码不太复杂的情况下，可以使用简化模型。
+
+## 代码例子
+
+下面例子使用 javascript 编写。
+
+```typescript
+class Director {
+  create(concreteBuilder: ConcreteBuilder) {
+    // 创建了一些零件
+    concreteBuilder.buildA();
+    concreteBuilder.buildB();
+
+    // 校验参数已经生成实例
+    return concreteBuilder.build();
+  }
+}
+
+class HouseBuilder {
+  public buildA() {
+    // 创建房屋
+    // this.xxx = xxx
+  }
+
+  public buildB() {
+    // 刷油漆
+  }
+
+  public build() {
+    // 最终创建实例
+    return new House(/* ..一堆参数 this.xxx.. */);
+  }
+}
+
+// 接下来是正式使用
+const director = new Director();
+const builder = HouseBuilder();
+const house = director.create(builder);
+```
+
+上面的例子是完整版本的 Builder 模式，抽象了指导器 `Director` 与生成器 `Builder`，只要两者都严格按照接口实现，我们可以：
+
+1. 替换任意 `Director`，使创建的过程做任意修改。
+2. 替换任意 `Builder`，使创建的实现做任意修改。
+
+做了任意的改动，都可以得到不同的房子实现，这就是创建与表示分离的好处，我们可以通过同样的构建过程创建不同的表示。
+
+这个 `director.create()`：
+
+- 在搭乐高积木的例子，表示用乐高搭建房屋的过程。
+- 在工程流水线的例子，表示罐头的组装构成。
+- 在创建数据库连接池的例子，表示数据库连接池的创建过程。
+
+而 `Builder` 以及其函数 `buildA` `buildB` 等方法表示具体制造方法，比如：
+
+- 在搭乐高积木的例子，表示如何盖房子，如何刷油漆。
+- 在工程流水线的例子，表示如何做一个罐头，如何添加黄桃。
+- 在创建数据库连接池的例子，表示如何设置数据库地址，如何设置用户名密码等。
+
+对于数据库的例子中，我们不仅可以保证创建对象的便捷性，因为不需要传入过多参数，也保证了对象的正确校验，同时生成的实例也是不可变的。
+
+更重要的是，如果使用完整模式，我们可以替换 `Director` 来修改创建数据库的方式，替换 `Builder` 来修改具体方法，比如 `.setUserName` 这个函数不做具体实现，而是统计性能，`build()` 函数创建的不是一个数据库连接实例，而是一个测试实例。
+
+再比如前端同一个方法在 JS 和 Node 环境下运行效果不一样，我们可以实现 `BrowserBuild` 与 `NodeBuild`，实现相同的接口，这样可以共享相同的创建过程，创建不同环境可以运行的实例。
+
+可以看到，使用 Builder 模式可以保证创建对象的便捷与稳定性，还留了足够的拓展空间改变对象的创建过程与创建方法，具有极强的拓展性。
+
+## 弊端
+
+任何设计模式都有其适用场景，反过来也说明了在某些场景下不适用。
+
+- 实例化对象非常繁琐，重复定义了许多对象成员变量的 `set` 方法，而且也不如 `new` 看的直观，也就是场景足够简单时，不需要任何地方都用 Builder 实例化对象。
+- 一个对象只有一种表示时，没必要做如此地步的抽象。
+
+上面的例子都是相对复杂的，假设我们的搭房子的例子中，我们不是用乐高积木搭建，而是用两块半成品模板拼起来就得到一个房子，那就没有必要使用 Builder 模式，直接 `new House()` 即可。
+
+再者，如果我们只需要生产各种罐头，而不需要生产汽车，那么就没必要过度抽象 Builder，把创建汽车的方法也囊括进去，最后，如果我们的对象只有一种表示时，没有必要抽象 Builder，也就是流水线如果只生产黄桃罐头，就没必要把各个生产环节变成可拆卸的，因为也没有重新组合的需要。
+
+## 总结
+
+Builder 模式对于创建一个复杂对象特别有用，可以看下图加深理解：
+
+<img wdith=800 src="https://img.alicdn.com/tfs/TB109aLYoT1gK0jSZFrXXcNCXXa-1412-984.png">
+
+最后总结一下何时适合用 Builder 模式：只有当创建过程允许被构造对象有不同表示，或者对象复杂到对象描述与创建对象过程值得分离时，才使用 Builder 设计模式。
+
+> 讨论地址是：[精读《设计模式 - Builder 生成器》· Issue #273 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/273)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

169.精读《设计模式 - Factory Method 工厂方法》.md

@@ -0,0 +1,115 @@
+# Factory Method（工厂方法）
+
+Factory Method（工厂方法）属于创建型模式，利用工厂方法创建对象实例而不是直接用 New 关键字实例化。
+
+理解如何写出工厂方法很简单，但理解为什么要用工厂方法就需要动动脑子了。工厂方法看似简单的将 New 替换为一个函数，其实是体现了面向接口编程的思路，它创建的对象其实是一个符合通用接口的通用对象，这个对象的具体实现可以随意替换，以达到通用性目的。
+
+**意图：定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使一个类的实例化延迟到其子类。**
+
+## 举例子
+
+如果看不懂上面的意图介绍，没有关系，设计模式需要在日常工作里用起来，结合例子可以加深你的理解，下面我准备了三个例子，让你体会什么场景下会用到这种设计模式。
+
+### 换灯泡
+
+我自己在家换过灯泡，以前我家里灯坏掉的时候，我看着这个奇形怪状的灯管，心里想，这种灯泡和这个灯座应该是一体的，市场上估计很难买到适配我这个灯座的灯泡了。结果等我把灯泡拧下来，跑到门口的五金店去换的时候，店员随便给了我一个灯泡，我回去随便拧了一下居然就能用了。
+
+我买这个灯泡的过程就用到了工厂模式，而正是得益于这种模式，让我可以方便在家门口就买到可以用的灯泡。
+
+### 卡牌对战游戏
+
+卡牌对战中，卡牌有一些基本属性，比如攻防、生命值，也符合一些通用约定，比如一回合出击一起等等，那么对于战斗系统来说，应该怎样实例化卡牌呢？如何批量操作卡牌，而不是通用功能也要拿到每个卡牌的实例才能调用？另外每个卡牌有特殊能力，这些特殊能力又应该如何拓展呢？
+
+### 实现任意图形拖拽系统
+
+一个可以被交互操作的图形，它可以用鼠标进行拉伸、旋转或者移动，不同图形实现这些操作可能并不相同，要存储的数据也不一样，这些数据应该独立于图形存储，我们的系统如果要对接任意多的图形，具备强大拓展能力，对象关系应该如何设计呢？
+
+## 意图解释
+
+在使用工厂方法之前，我们就要创建一个 **用于创建对象的接口**，这个接口具备通用性，**所以我们可以忽略不同的实现来做一些通用的事情**。
+
+换灯泡的例子来说，我去门口五金店买灯泡，而不是拿到灯泡材料自己 New 一个出来，就是因为五金店这个 “工厂” 提供给我的灯泡符合国家接口标准，而我家里的灯座也符合这个标准，所以灯座不需要知道对接的灯泡是具体哪个实例，什么颜色，什么形状，这些都无所谓，只要灯泡符合国家标准接口，就可以对接上。
+
+对卡牌对战的系统来说，**所有卡牌都应该实现同一种接口**，所以卡牌对战系统拿到的卡牌应该就是简单的 Card 类型，这种类型具备基本的卡片操作交互能力，系统就调用这些能力完成基本流程就好了，如果系统直接实例化具体的卡片，那不同的卡片类型会导致系统难以维护，卡片间操作也无法抽象化。
+
+正式这种模式，使得我们可以在卡牌的具体实现上做一些特殊功能，比如修改卡片攻击时效果，修改卡牌销毁时效果。
+
+对图形拖拽系统来说，用到了 “连接平行的类层次” 这个特性，所谓连接平行的类层次，就是指一个图形，与其对应的操作类是一个平行抽象类，而一个具体的图形与具体的操作类则是另一个平行关系，系统只要关注最抽象的 “通用图形类” 与 “通用操作类” 即可，操作时，底层可能是某个具体的 “圆类” 与 “圆操作类” 结合使用，具体的类有不同的实现，但都符合同一种接口，因此操作系统才可以把它们一视同仁，统一操作。
+
+**意图：定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使一个类的实例化延迟到其子类。**
+
+所以接口是非常重要的，工厂方法第一句话就是 “定义一个用于创建对象的接口”，这个接口就是 `Creator`，让子类，也就是具体的创建类（`ConcreteCreator`）决定要实例化哪个类（`ConcreteProduct`）。
+
+所谓使一个类的实例化延迟到其子类，是因为抽象类不知道要实例化哪个具体类，所以实例化动作只能由具体的子类去做，这样绕一圈的好处是，我们可以将任意多对象看作是同一类事物，做统一的处理，比如 **无论何种灯泡实例都满足通用的灯座接口**，**所有工厂实例化的卡牌都具备玩一局卡牌游戏的基本功能**，**任何图形与交互类都满足特定功能关系**，这种思想让生活和设计得到了大幅简化。
+
+## 结构图
+
+<img width=800 src="https://img.alicdn.com/tfs/TB1VjyZmsVl614jSZKPXXaGjpXa-1434-476.png">
+
+`Creator` 就是工厂方法，`ConcreteCreator` 是实现了 `Creator` 的具体工厂方法，每一个具体工厂方法生产一个具体的产品 `ConcreteProduct`，每个具体的产品都实现通用产品的特性 `Product`。
+
+## 代码例子
+
+下面例子使用 typescript 编写。
+
+```typescript
+// 产品接口
+interface Product {
+  save: () => void;
+}
+
+// 工厂接口
+interface Creator {
+  createProduct: () => Product;
+}
+
+// 具体产品
+class ConcreteProduct implements Product {
+  save = () => {};
+}
+
+// 具体工厂
+class ConcreteCreator implements Creator {
+  createProduct = () => {
+    return new ConcreteProduct();
+  };
+}
+```
+
+创建一个 `Product` 的子类 `ConcreteCreator`，并返回一个实现了 `Product` 的具体实例 `ConcreteProduct`，这样我们就可以方便使用这个工厂了。
+
+工厂方法并不是直接调用 `new ConcreteCreator().createProduct` 那么简单，这样体现不出任何抽象性，真正的场景是，在一个创建产品的流程中，我们只知道拿到的工厂是 `Creator`：
+
+```typescript
+function main(anyCreator: Creator) {
+  const product = anyCreator.createProduct()
+}
+```
+
+在外面调用 `main` 函数时，实际传进去的是一个具体工厂，比如 `myCreator`，但关键是 `main` 函数不用关心到底是哪一个具体工厂，只要知道是个工厂就行了，具体对象创建过程交给了其子类。
+
+**你也许也发现了，这就是抽象工厂中其中的一步，所以抽象工厂使用了工厂方法。**
+
+## 弊端
+
+工厂方法中，每创建一种具体的子类，就要写一个对应的 `ConcreteCreate`，这相对比较笨重，但有意思的是，如果将创建多个对象放到一个 `ConcreteCreate` 中，就变成了 **简单工厂模式**，新增产品要修改已有类不符合开闭模式，反而推荐写成本文说的这种模式。
+
+彼之毒药吾之蜜糖，要知道没有一种设计模式解决所有问题，没有一种设计模式没有弊端，**而这个弊端不代表这个设计模式不好，一个弊端的出现可能是为了解决另一个痛点。** 要接受不完美的存在，这么多种设计模式就是对应了不同的业务场景，**为合适的场景选择一种能将优势发扬光大，以至于能掩盖弊端，就算进行了合理的架构设计**。
+
+## 总结
+
+工厂方法并不是简单把 New 的过程换成了函数，而是抽象出一套面向接口的设计模式：
+
+<img width=800 src="https://img.alicdn.com/tfs/TB1WKH.Zoz1gK0jSZLeXXb9kVXa-1480-786.png">
+
+你看，我要做灯泡，可以直接做具体的灯泡，也可以定一个灯泡接口，通过灯泡工厂拿到具体灯泡，灯泡工厂对待所有灯泡的只做流程都是一样的，不管是中世纪风灯泡，还是复古灯泡，还是普通白织灯，都是一模一样的制作流程，具体怎么做由具体的子类去实现，这样我们可以统一管理 “灯泡” 这一个通用概念，而忽略不同灯泡之间不太重要的差别，程序的可维护性得到了大幅提升。
+
+> 讨论地址是：[精读《设计模式 - Factory Method 工厂方法》· Issue #274 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/274)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

170.精读《设计模式 - Prototype 原型模式》.md

@@ -0,0 +1,121 @@
+# Prototype（原型模式）
+
+Prototype（原型模式）属于创建型模式，既不是工厂也不是直接 New，而是以拷贝的方式创建对象。
+
+**意图：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。**
+
+## 举例子
+
+如果看不懂上面的意图介绍，没有关系，设计模式需要在日常工作里用起来，结合例子可以加深你的理解，下面我准备了三个例子，让你体会什么场景下会用到这种设计模式。
+
+### 做钥匙
+
+很显然，为了房屋安全，要尽量做到一把钥匙只能开一扇门，每把钥匙结构都多多少少不一样，却又很相似，做钥匙的人按照你给的钥匙一模一样做一个新的，这属于什么模式呢？
+
+### 两种状态表
+
+当网站做不停机维护时，假设维护内容是给每个高级会员账户多打 100 元现金，现在需要改数据库表。已知：
+
+1. 数据库表有几千万条数据，其中高级会员有几千位，为了方便调用已经缓存在中间层了，且数据库对应 ID 更新后对应缓存也会更新。
+2. 几千条数据修改语句执行完需要几分钟，这几分钟内无法接受用户数据不同步的问题。
+
+一种常见的做法是，我们生成一份高级会员列表的拷贝，代替数据库缓存的结果，数据库只要读到对应会员 ID 就从拷贝列表中获取，数据表新增一列状态标志，操作完后这个拷贝移除，更新高级会员缓存。
+
+但是如何生成高级会员列表拷贝呢？如果直接从几千万条用户数据中重新查询，会有较高的数据库查询成本。
+
+### 模版组件
+
+通用搭建系统中，我们可以将某个拖拽到页面的区块设置为 “模版”，这个模版可以作为一个新组件被重新拖拽到任意为止，实例化任意次。实际上，这是一种分段式复制粘贴，你会如何实现这个功能呢？
+
+## 意图解释
+
+解决上面问题的办法都很简单，就是基于已有对象进行复制即可，效率比 New 一个，或者工厂模式都要高。
+
+**意图：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。**
+
+所谓原型实例，就是被选为拷贝模版的那个对象，比如做钥匙例子中，你给老板的样板钥匙；两种状态表中的已有缓存高级会员列表；模版组件中选中的那个组件。然后，通过拷贝这些原型创建你想要的对象即可。
+
+我们抽象思考一下，如果每把钥匙都遵循 `Prototype` 接口，提供了 `clone()` 方法以复制自己，那就可以快速复制任意一把钥匙。钥匙工厂可无法解决每把钥匙不一样的问题，我们要的就是和某个钥匙一模一样的副本，复制一份钥匙最简单。
+
+高级会员状态表例子中，查询数据库的成本是高昂的，但如果仅仅复制已经查询好的列表，时间可以忽略不计，因此最经济的方案是直接复制，而不是通过工厂模式重新连接数据库并执行查询。
+
+模版组件更是如此，我们根本没有定义那么多组件实例的基类，只要每个组件提供一个 `clone()` 函数，就可以立即复制任意组件实例，这无疑是最经济实惠的方案。
+
+看到这里，你应该知道了，原型模式的精髓是对象要提供 `clone()` 方法，而这个 `clone()` 方法实现难度有高有低。
+
+一般来说，原型模式的拷贝建议用深拷贝，毕竟新对象最好不要影响到旧对象，**但是在深拷贝性能问题较大的情况下，可以考虑深浅拷贝结合，也就是将在新对象中，不会修改的数据使用浅拷贝，可能被修改的数据使用深拷贝。**
+
+## 结构图
+
+<img width=800 src="https://img.alicdn.com/tfs/TB1roQlZWL7gK0jSZFBXXXZZpXa-1328-596.png">
+
+`Client` 是发出指令的客户端，`Prototype` 是一个接口，描述了一个对象如何克隆自身，比如必须拥有 `clone()` 方法，而 `ConcretePrototype` 就是克隆具体的实现，不同对象有不同的实现来拷贝自身。
+
+## 代码例子
+
+下面例子使用 typescript 编写。
+
+```typescript
+class Component implements Prototype {
+  /**
+   * 组件名
+   */
+  private name: string
+  /**
+   * 组件版本
+   */
+  private version: string
+
+  /**
+   * 拷贝自身
+   */
+  public clone = () => {
+    // 构造函数省略了，大概就是传递 name 和 version
+    return new Component(this.name, this.version)
+  }
+}
+```
+
+我们可以看到，实现了 `Prototype` 接口的 `Component` 必须实现 `clone` 方法，这样任意组件在执行复制时，就可以直接调用 `clone` 函数，而不用关心每个组件不同的实现方式了。
+
+从这就能看出，原型模式与 Factory 与 Builder 模式还是有类似之处的，在隐藏创建对象细节这一点上。
+
+使用的时候，我们就可以这样创建一个新对象：
+
+```typescript
+const newComponent = oldComponent.clone()
+```
+
+这里有两个注意点：一般来说，**如果要二次修改生成的对象，不建议给 `clone` 函数加参数，因为这样会导致接口的不一致。** 我们可以为对象实例提供一些 `set` 函数进行二次修改。另外，`clone` 函数要考虑性能，就像前面说过的，可以考虑深浅拷贝结合的方式，同时要注意当对象存在引用关系甚至循环引用时，甚至不一定能实现拷贝函数。
+
+## 弊端
+
+每个设计模式必有弊端，但就像每一期都说的，有弊端不代表设计模式不好用，而是指在某种场景喜爱存在问题，我们只要规避这些场景，在合理的场景使用对应设计模式即可。
+
+原型模式的弊端：
+
+1. 每个类都要实现 `clone` 方法，对类的实现是有一定入侵的，要修改已有类时，违背了开闭原则。
+2. 当类又调用了其他对象时，如果要实现深拷贝，需要对应对象也实现 `clone` 方法，整体链路可能会特别长，实现起来比较麻烦。
+
+## 总结
+
+**原型模式一般与工厂模式搭配使用，一般工厂方法接收一个符合原型模式的实例，就可以调用它的 `clone` 函数创建返回新对象啦。** 代码大概是这样：
+
+```typescript
+// buildComponentFactory 内部通过 targetComponent.clone() 创建对象，而不是 New 或者调用其他工厂函数。
+const newComponent = buildComponentFactory(new Component())
+```
+
+最后来一张图快速理解原型模式：
+
+<img width=600 src="https://img.alicdn.com/tfs/TB1hBIdm6MZ7e4jSZFOXXX7epXa-982-486.png">
+
+> 讨论地址是：[精读《设计模式 - Prototype 原型模式》· Issue #277 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/277)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

171.精读《设计模式 - Singleton 单例模式》.md

@@ -0,0 +1,115 @@
+# Singleton（单例模式）
+
+Singleton（单例模式）属于创建型模式，提供一种对象获取方式，保证在一定范围内是唯一的。
+
+**意图：保证一个类仅有一个实例，并提供一个访问它的全局访问点。**
+
+其实单例模式在前端体会的不明显，原因有：
+
+1. 前端代码本身在单机运行，创建的任何变量都是天然分布式的，不需要担心影响另一个用户。
+2. 后端代码是一对多的，分辨出哪些资源是请求间共享的，哪些是请求内独有的很重要。
+
+另外我们说到单例，是隐含了一个范围的，指的是在某个范围内单例，比如在一个上下文中，还是一个房间中，还是一个进程，一个线程中单例，不同场景范围会不同。
+
+## 举例子
+
+如果看不懂上面的意图介绍，没有关系，设计模式需要在日常工作里用起来，结合例子可以加深你的理解，下面我准备了三个例子，让你体会什么场景下会用到这种设计模式。
+
+### 多人游戏的共享物品
+
+玩过游戏的同学都知道，我们在每局游戏中使用的公共物品在当前房间中是唯一的，但在游戏房间间却不是唯一的，所以这些公共物品肯定有不同的类去描述，那每局游戏中怎么拿公共物品，可以保证拿到的是当前局内唯一的？
+
+### Redux 数据流
+
+其实前端的 Redux 数据流本身就是单例模式，在一个应用中，数据是唯一的，但可以有不同的 UI 使用这份唯一的数据，甚至把一个表格组件展示在两个不同地方，比如全屏模式，但数据依然是一份，我们没有必要为了全屏展示表格，就让它再发一次取数请求，完全可以和原来的表格共享一份数据。
+
+### 数据库连接池
+
+每个 SQL 查询都依赖数据库连接池，如果每次查询都建立一次数据库连接池，则建立连接的速度会远远慢于 SQL 查询速度，因此你会怎么设计数据库连接池的获取方法？
+
+## 意图解释
+
+单例模式的意图很简单，几乎就是其字面含义：
+
+**意图：保证一个类仅有一个实例，并提供一个访问它的全局访问点。**
+
+对于多人游戏的共享物品，比如一口锅，要保证在一局游戏内唯一，就要提供一种方法访问到唯一实例。
+
+Redux 数据流的 `connect` 装饰器就是全局访问点的一种设计。
+
+数据库连接池可以提前初始化好，并通过固定 API 提供这个唯一实例。
+
+## 结构图
+
+<img width=600 src="https://img.alicdn.com/tfs/TB1qVf20QY2gK0jSZFgXXc5OFXa-1060-342.png">
+
+`Singleton` 是单例模式的接口，客户只能通过其定义的 `instance()` 访问实例，以保证单例。
+
+## 代码例子
+
+下面例子使用 typescript 编写。
+
+```typescript
+class Ball {
+  private _instance = undefined
+
+  // 构造函数申明为 private，就可以阻止 new Ball() 行为
+  private constructor() {}
+
+  public static getInstance = () => {
+    if (this._instance === undefined) {
+      this._instance = new Ball()
+    }
+
+    return this._instance
+  }
+}
+
+// 使用
+const ball = Ball.getInstance()
+```
+
+可以仔细想想，为什么这个例子把单例写成了静态方法，而不是一个全局变量？其实全局变量也能解决问题，但由于会污染全局，要尽可能通过模块化方式解决，上面的例子就是一个较好的封装方式。
+
+当然这只是一个最简单的例子，实际上单例模式还有几种模式：
+
+### 饿汉式
+
+初始化时就生成一份实例，这样调用时直接就能获取。
+
+### 懒汉式
+
+就是代码例子中写的，按需实例化，即调用的时候再实例化。
+
+> **要注意，按需不一定是什么好事，如果 New 的成本很高还按需实例化，可能把系统异常的风险留到随机的触发时机，导致难以排查 BUG，另外也会影响第一次实例化时的系统耗时。**
+
+对 JAVA 来说，单例还需要考虑并发性，有 **双重检测、静态内部类、枚举** 等办法解决，这里不具体展开。
+
+## 弊端
+
+单例模式的问题有：
+
+- 对面向对象不太友好。对封装、继承、多态支持不够友好。
+- 不利于梳理类之间的依赖关系。毕竟单例是直接调用的，而不是在构造函数申明的，所以要梳理关系要看完每一行代码才能确定。
+- 可拓展性不好。万一要支持多例就比较难拓展，比如全局数据流可能因为微前端方案改成多实例、数据库连接池为了分治 SQL 改成多实例，都是有可能的，在系统设计之初就要考虑到未来是否还会保持单例。
+- 可测试性不好，因为单例是全局共享的，无法保证测试用例间的隔离。
+- 无法使用构造函数传参。
+
+另外单例模式还可以被工厂方法所替代，所以不用特别纠结一种设计模式，可以结合使用，工厂函数也可以内嵌单例模式。
+
+## 总结
+
+单例模式概念、用法都简单，是架构设计常用方案，但要充分理解到单例模式的弊端，防止不恰当的使用。
+
+<img width=400 src="https://img.alicdn.com/tfs/TB15O3YmOpE_u4jSZKbXXbCUVXa-904-224.png">
+
+
+> 讨论地址是：[精读《设计模式 - Singleton 单例模式》· Issue #278 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/278)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

172.精读《设计模式 - Adapter 适配器模式》.md

@@ -0,0 +1,149 @@
+# Adapter（适配器模式）
+
+Adapter（适配器模式）属于结构型模式，别名 `wrapper`，结构性模式关注的是如何组合类与对象，以获得更大的结构，我们平常工作大部分时间都在与这种设计模式打交道。
+
+**意图：将一个类的接口转换成客户希望的另一个接口。Adapter 模式使得原本由于接口不兼容而不能在一起工作的那些类可以一起工作。**
+
+这个设计模式的意图很好懂，就是把接口不兼容问题抹平。注意，也仅仅能解决接口不一致的问题，而不能解决功能不一致的问题。
+
+## 举例子
+
+如果看不懂上面的意图介绍，没有关系，设计模式需要在日常工作里用起来，结合例子可以加深你的理解，下面我准备了三个例子，让你体会什么场景下会用到这种设计模式。
+
+### 接口转换器
+
+插座的种类很多，我们都用过许多适配器，将不同的插头进行转换，可以在不替换插座的情况下正常使用。
+
+USB 接口转换也同样精彩，有将 TypeC 接口转换为 TypeA 的，也有将 TypeA 接口转换为 TypeC 的，支持双向转换。
+
+接口转换器就是我们在生活中使用到的适配器模式，因为厂商并没有生产一个新的插座，我们也没有因为接口不适配而换一个手机，一切只需要一个接口转换器即可，这就是运用设计模式的收益。
+
+### 数据库 ORM
+
+ORM 屏蔽了 SQL 这一层，带来的好处是不需要理解不同 SQL 语法之间的区别，对于通用功能，ORM 会根据不同的平台，比如 Postgresql、Mysql 进行 SQL 的转换。
+
+对 ORM 来说，屏蔽不同平台的差异，就是利用适配器模式做到的。
+
+### API Deprecated
+
+当一个广泛使用的库进行了含有 break change 的升级时，往往要留给开发者足够的时间去升级，而不能升级后就直接挂掉，因此被废弃的 API 要标记为 `deprecated`，而这种被废弃标记的 API 的实际实现，往往是使用新的 API 替代，这种场景正是使用了适配器模式，将新的 API 适配到旧的 API，实现 API Deprecated。
+
+## 意图解释
+
+上面三个例子都满足下面两个条件：
+
+1. API 不兼容：因为接口的不同；数据库 SQL 语法的不同；框架 API 的不同。
+2. 但能力已支持：插座都拥有充电或读取能力；不同的 SQL 都拥有查询数据库能力；新 API 覆盖了旧 API 的能力。
+
+这样就可以通过适配器满足 Adapter 的意图：
+
+**意图：将一个类的接口转换成客户希望的另一个接口。Adapter 模式使得原本由于接口不兼容而不能在一起工作的那些类可以一起工作。**
+
+## 结构图
+
+适配器的实现分为继承与组合模式。
+
+下面是名词解释：
+
+- `Adapter` 适配器，把 `Adeptee` 适配成 `Target`。
+- `Adaptee` 被适配的内容，比如不兼容的接口。
+- `Target` 适配为的内容，比如需要用的接口。
+
+继承：
+
+<img width=400 src="https://img.alicdn.com/tfs/TB1iy7Gk4vbeK8jSZPfXXariXXa-1590-518.png">
+
+适配器继承 `Adaptee` 并实现 `Target`，适用场景是 `Adaptee` 与 `Target` 结构类似的情况，因为这样只需要实现部分差异化即可。
+
+组合：
+
+<img width=400 src="https://img.alicdn.com/tfs/TB1SrW21EY1gK0jSZFMXXaWcVXa-1524-500.png">
+
+组合的拓展性更强，但工作量更大，如果 `Target` 与 `Adaptee` 结构差异较大，适合用组合模式。
+
+## 代码例子
+
+下面例子使用 typescript 编写。
+
+继承：
+
+```typescript
+interface ITarget {
+  // 标准方式是 hello
+  hello: () => void
+}
+
+class Adaptee {
+  // 要被适配的类方法叫 sayHello
+  sayHello() {
+    console.log('hello')
+  }
+}
+
+// 适配器继承 Adaptee 并实现 ITarget
+class Adapter extends Adaptee implements ITarget {
+  hello() {
+    // 用 sayHello 对接到 hello
+    super.sayHello()
+  }
+}
+```
+
+组合：
+
+```typescript
+interface ITarget {
+  // 标准方式是 hello
+  hello: () => void
+}
+
+class Adaptee {
+  // 要被适配的类方法叫 sayHello
+  sayHello() {
+    console.log('hello')
+  }
+}
+
+// 适配器继承 Adaptee 并实现 ITarget
+class Adapter implements ITarget {
+  private adaptee: Adaptee 
+
+  constructor(adaptee: Adaptee) {
+    this.adaptee = adaptee
+  }
+
+  hello() {
+    // 用 adaptee.sayHello 对接到 hello
+    this.adaptee.sayHello()
+  }
+}
+```
+
+## 弊端
+
+**使用适配器模式本身就可能是个问题**，因为一个好的系统内部不应该做任何侨界，模型应该保持一致性。只有在如下情况才考虑使用适配器模式：
+
+1. 新老系统接替，改造成本非常高。
+2. 三方包适配。
+3. 新旧 API 兼容。
+4. 统一多个类的接口。一般可以结合工厂方法使用。
+
+## 总结
+
+适配器模式也符合开闭原则，在不对原有对象改造的前提下，构造一个适配器就能完成模块衔接。
+
+适配器模式的实现分为类与对象模式，类模式用继承，对象模式用组合，分别适用于 `Adaptee` 与 `Target` 结构相似与结构差异较大的场景，在任何情况下，组合模式都是灵活性最高的。
+
+最后用一张图概括一下适配器模式的思维：
+
+<img width=400 src="https://img.alicdn.com/tfs/TB16L2n1AY2gK0jSZFgXXc5OFXa-1254-630.png">
+
+> 讨论地址是：[精读《设计模式 - Adapter 适配器模式》· Issue #279 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/279)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

173.精读《设计模式 - Bridge 桥接模式》.md

@@ -0,0 +1,111 @@
+# Bridge（桥接模式）
+
+Bridge（桥接模式）属于结构型模式，是一种解决继承后灵活拓展的方案。
+
+**意图：将抽象部分与它的实现部分分离，使它们可以独立地变化。**
+
+桥接模式比较难理解，我会一步步还原该设计模式的思考，让你体会这个设计模式是如何一步一步被提炼出来的。
+
+## 举例子
+
+如果看不懂上面的意图介绍，没有关系，设计模式需要在日常工作里用起来，结合例子可以加深你的理解，下面我准备了三个例子，让你体会什么场景下会用到这种设计模式。
+
+### 汽车生产线改造为新能源生产线
+
+汽油车与新能源汽车的生产流程有很大相似之处，那么汽油车生产线能否快速改造为新能源汽车生产线呢？
+
+如果汽油车生产线没有将内部实现解耦，只把生产汽油车的各部分独立了出来，对新能源车生产线是没什么用处的，但如果汽油车生产线提供了更底层的能力，比如加装轮胎，加装方向盘，那么这些步骤是可以同时被汽油车与新能源车所共享的。
+
+在设计汽油车生产线时，就将生产过程与汽油车解耦，使其可以快速运用到新能源汽车的生产，这就是桥接模式的一种运用。
+
+### 窗口（Window）类的派生
+
+假设存在一个 Window 窗口类，其底层实现在不同操作系统是不一样的，假设对于操作系统 A 与 B，分别有 AWindow 与 BWindow 继承自 Window，现在要做一个新功能 ManageWindow（管理器窗口），就要针对操作系统 A 与 B 分别生成 AManageWindow 与 BManageWindow，这样显然不容易拓展。
+
+无论我们新增支持 C 操作系统，还是新增支持一个 IconWindow，类的数量都会成倍提升，因为我们所做的 AMangeWindow 与 BMangeWindow 同时存在两个即以上的独立维度，这使得增加维度时，代码变得很冗余。
+
+### 适配多个搭建平台的物料
+
+做前端搭建平台时，经常出现一些物料（组件）因为固化了某个搭建平台的 API，因此无法迁移到另一个搭建平台，如果要迁移，就需要为不同的平台写不同的组件，而这些组件中大部分 UI 逻辑都是一样的，这使得产生大量代码冗余，如果再兼容一个新搭建平台，或者为已有的 10 个搭建平台再创建一个新组件，工作量都是写一个组件的好几倍。
+
+## 意图解释
+
+**意图：将抽象部分与它的实现部分分离，使它们可以独立地变化。**
+
+“抽象” 部分与 “实现” 部分分离，这句话看起来很像接口与实现。确实，如果 “抽象” 指的是 接口(Interface)，而 “实现” 指的是 类(Class) 的话，这就是简简单单的 `class MyWindow implements Window` 类实现过程而已。
+
+但后半句话 “使它们可以独立地变化” 会让你难以和前半句联系起来，如果说 “抽象” 不变，“实现” 可以随意改变还好理解，但反过来就难以解释了。
+
+**其实桥接模式中，抽象指的是一种接口（Abstraction），实现指的也是一种接口（Implementor），其中 Implementor 并不是直接实现了 Abstraction 定义的接口，而是提供更底层的方法，使 Abstraction 可以基于它们封装出自己的接口实现。**
+
+这样一来，Abstraction 的接口可以随意变化，毕竟调用的是 Implementor 提供函数的组合，只要 Implementor 提供的功能全面，Implementor 可以不变；相应的，Implementor 的实现也可以随意变化，只要提供的底层函数不变，就不影响 Abstraction 对其的使用。
+
+上面举的三个例子都是这样，我们应该把汽油车生产线的标准与通用汽车生产线标准分离、将具体功能窗口与适配不同操作系统的基础 GUI 能力隔离、将组件功能与平台功能隔离，只有做到了抽象部分与实现部分的隔离，才可以通过组合满足更多场景。
+
+## 结构图
+
+<img width=600 src="https://img.alicdn.com/tfs/TB1mZv52oH1gK0jSZSyXXXtlpXa-1726-696.png">
+
+- Abstraction：定义抽象类的接口。
+- RefinedAbstraction：扩充 Abstraction。
+- Implementor：定义实现类的接口，该接口可以与 Abstraction 接口不一致。
+- ConcreteImplementor：实现 Implementor 接口并定义它的具体实现。
+
+抽象部分就是 Abstraction，实现部分就是 Implementor，在这个结构图中，它们是分离的，可以各自独立变化的，桥接模式，就是指 `imp` 这个桥，通过 Implementor 实现 Abstraction 接口，就算是桥接上了，这种组合的桥接相比普通的类实现更灵活，更具有拓展性。
+
+## 代码例子
+
+对于完全版桥接模式，Implementor 可以有多套实现，Abstraction 不需关心具体用的是哪一种实现，而是通过抽象工厂方式封装。下面举一个简单版的例子。
+
+下面例子使用 typescript 编写。
+
+```typescript
+class Window {
+  private windowImp: WindowImp
+
+  public drawBox() {
+    // 通过画线生成 box
+    this.windowImp.drawLine(0, 1)
+    this.windowImp.drawLine(1, 1)
+    this.windowImp.drawLine(1, 0)
+    this.windowImp.drawLine(0, 0)
+  }
+}
+
+// 拓展 window 就非常容易
+class SuperWindow extends Window {
+  public drawIcon {
+    // 通过自定义画线
+    this.windowImp.drawLine(0, 5)
+    this.windowImp.drawLine(3, 9)
+  }
+}
+```
+
+桥接模式的精髓，通过上面的例子可以这么理解：
+
+`Window` 的能力是 `drawBox`，那继承 `Window` 容易拓展 `drawIcon` 吗？默认是不行的，因为 `Window` 并没有提供这个能力。经分析可以看出，划线是一种基础能力，不应该与 `Window` 代码耦合，因此我们将基础能力放到 `windowImp` 中，这样 `drawIcon` 也可以利用其基础能力画线了。
+
+## 弊端
+
+不要过度抽象，桥接模式是为了让类的职责更单一，维护更便捷，但如果只是个小型项目，桥接模式会增加架构设计的复杂度，而且不正确的模块拆分，把本来关联的逻辑强制解耦，在未来会导致更大的问题。
+
+另外桥接模式也有简单与复杂模式之分，只有一种实现的场景就不要用抽象工厂做过度封装了。
+
+## 总结
+
+桥接模式让我们重新审视类的设计是否合理，把类中不相关，或者说相互独立的维度抽出去，由桥接模式做桥接的方式使用，这样会使每个类功能更内聚，代码量更少更清晰，组合能力更强大，更容易做拓展。
+
+下图做了一个简单的解释：
+
+<img width=500 src="https://img.alicdn.com/tfs/TB1nossndTfau8jSZFwXXX1mVXa-1308-1078.png">
+
+> 讨论地址是：[精读《设计模式 - Bridge 桥接模式》· Issue #280 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/280)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

174.精读《设计模式 - Composite 组合模式》.md

@@ -0,0 +1,111 @@
+# Composite（组合模式）
+
+Composite（组合模式）属于结构型模式，是一种统一管理树形结构的抽象方式。
+
+**意图：将对象组合成树形结构以表示 “部分 - 整体” 的层次结构。Composite 使得用户对单个对象和组合对象的使用具有一致性。**
+
+## 举例子
+
+如果看不懂上面的意图介绍，没有关系，设计模式需要在日常工作里用起来，结合例子可以加深你的理解，下面我准备了三个例子，让你体会什么场景下会用到这种设计模式。
+
+### 公司组织关系树
+
+公司组织关系可能分为部门与人，其中人属于部门，有的人有下属，有的人没有下属。如果我们统一将部门、人抽象为组织节点，就可以方便的统计某个部门下有多少人、财务数据等等，而不用关心当前节点是部门还是人。
+
+### 操作系统的文件夹与文件
+
+操作系统的文件夹与文件也是典型的树状结构，为了方便递归出文件夹内文件数量或者文件总大小，我们最好设计的时候就将文件夹与文件抽象为文件，这样每个节点都拥有相同的方法添加、删除、查找子元素，而不需要关心当前节点是文件夹或是文件。
+
+### 搭建平台的组件与容器
+
+容器与组件的关系很小，用户常常认为容器也是一种组件，但搭建平台实现时，容器与组件稍有不同，不同之处在于容器可以嵌套子元素，而组件不可以。如果因此搭建平台就将组件分为容器与组件，会导致 API 割裂为两套，不利于组件开发者维护与用户理解，比较好的设计思路是将组件与容器统一看成组件，组件只是一种没有子元素的特殊容器，这样组件与容器就可以拥有相同的 API，统一理解与操作了。
+
+## 意图解释
+
+**意图：将对象组合成树形结构以表示 “部分 - 整体” 的层次结构。Composite 使得用户对单个对象和组合对象的使用具有一致性。**
+
+比较好理解，组合是指多个对象虽然有一定差异，但共同组合成了一个树形结构，那么对象之间就一定存在 “部分 - 整体” 的关系，组合模式要求我们抽象一个对象 `Component` 作为统一操作模型，叶子结点与非叶子结点都实现了所有功能，即便是没有子元素的叶子结点，为了强调透明性，还是具备比如 `getChildren` 方法，只不过永远都返回 `null`。
+
+## 结构图
+
+<img width=600 src="https://img.alicdn.com/tfs/TB19t0j27Y2gK0jSZFgXXc5OFXa-1504-678.png">
+
+其中 `Component` 是组合中对象声明接口，一般会实现所有公共类的所有接口，还要提供一个接口管理其子组件。
+
+`Leaf` 表示叶子结点，没有子结点，相应的 `Composite` 就是有子结点的节点。
+
+可以看到，组合模式就是将树状结构中所有节点统一抽象了，**我们不需要关心叶子结点与非叶子结点的差异，而可以通过组合模式的抽象屏蔽掉这些差异，统一处理。**
+
+## 代码例子
+
+下面例子使用 typescript 编写。
+
+```typescript
+// 统一的抽象
+class Component {
+  // 添加子元素
+  public add() {}
+  // 获取名称
+  public getName() {}
+  // 获取子元素
+  public getChildren() {}
+}
+
+// 非叶子结点
+class Composite extends Component {
+  public add(component: Component) {
+    this.children.push(component)
+  }
+
+  public getName() {
+    return this.name
+  }
+
+  public getChildren() {
+    return this.children
+  }
+}
+
+// 叶子结点
+class Leaf extends Component {
+  public add(component: Component) {
+    throw Error('叶子结点无法添加元素')
+  }
+
+  public getName() {
+    return this.name
+  }
+
+  public getChildren() {
+    return null
+  }
+}
+```
+
+最后我们把对所有节点的操作都转为 `Component` 对象，而不用关心这个对象具体是 `Composite` 或 `Leaf`。
+
+## 弊端
+
+组合模式进行了一层抽象，其实增加了复杂系统中业务复杂度。如果 `Composite` 与 `Leaf` 差异过大，那么统一抽象带来的理解成本是很高的。
+
+同时，`Leaf` 不得不实现一些仅 `Composite` 存在的空函数，比如 `add` `delete`，即便这些方法对他们是无意义的，此时可能要进行统一的无效或错误处理，才能使业务层真正不用感知他们的区别，否则 `add` 可能会失败，其本质上还是将节点的区别暴露给了业务层。
+
+## 总结
+
+组合模式是针对树状结构这个特定场景的统一抽象方案，对降低系统复杂度有很重要的意义，同时也不要忘了过度抽象是有害的，我们要拿捏其中的度。
+
+下图做了一个简单的解释：
+
+<img width=500 src="https://img.alicdn.com/tfs/TB1_g24rvzO3e4jSZFxXXaP_FXa-1228-614.png">
+
+程序中始终关注 `Component` 就行了，树状结构的差异已经被抹平。
+
+> 讨论地址是：[精读《设计模式 - Composite 组合模式》· Issue #284 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/284)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

175.精读《设计模式 - Decorator 装饰器模式》.md

@@ -0,0 +1,104 @@
+# Decorator（装饰器模式）
+
+Decorator（装饰器模式）属于结构型模式，是一种拓展对象额外功能的设计模式，别名 `wrapper`。
+
+**意图：动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator 模式相比生成子类更为灵活。**
+
+## 举例子
+
+如果看不懂上面的意图介绍，没有关系，设计模式需要在日常工作里用起来，结合例子可以加深你的理解，下面我准备了三个例子，让你体会什么场景下会用到这种设计模式。
+
+### 相框
+
+照片 + 相框 = 带相框的照片，这背后就是一种装饰器模式：照片具有看的功能，相框具有装饰功能，在你看照片的基础上，还能看到精心设计的相框，增加了美感，同时相框还可以增加照片的保存时间与安全性。
+
+相框与照片是一种组合关系，任何照片都可以放到相框中，而不是每个照片生成一个特定的相框，显然，组合的方式更加灵活。
+
+### 带有缓存的文件读写
+
+假设我们有一个类 `FileIO` 用来读写文件，但是没有缓存能力，此时是新建一个 `CachedFileIO` 子类好，还是创建一个 `CachedIO`?
+
+一眼看上去好像 `CachedFileIO` 用起来更方便，而 `CachedIO` 的用法是 `new CachedIO(new FileIO())` 稍微麻烦一些，但如果我们增加一个网络读写类 `NetworkIO`，一个数据库读写类 `DBIO` 呢？
+
+显然，继承的方式会使子类数量极速膨胀，而组合的方式则非常灵活，生成一个支持缓存的网络读写器，只需要 `new CachedIO(new NetworkIO())` 即可，这就是组合灵活的地方。
+
+当然，为了实现这个能力，`CachedIO` 需要与 `FileIO`、`CachedFileIO`、`CachedIO` 继承自同一个类，具备相同的接口。
+
+### 搭建平台的组件 wrapper
+
+装饰器模式别名也叫 `wrapper`，`wrapper` 也经常在前端搭建场景中遇到，当搭建平台加载一个组件时，希望拓展其基础能力，一般会使用 `wrapper` 层对组件进行嵌套，`wrapper` 层就是在不改变 API 的基础上，对第三方组件进行增强。
+
+## 意图解释
+
+**意图：动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator 模式相比生成子类更为灵活。**
+
+不同于继承，组合可以在运行时进行，所以称之为 “动态添加”，这里的 “额外职责” 泛指一切功能，比如在按钮点击时进行一些 log 日志的打印，在绘制 text 文本框时，额外绘制一个滚动条和边框等等。
+
+“就增加功能来说，Decorator 模式相比生成子类更为灵活” 这句话的含义是，组合比继承更灵活，当可拓展的功能很多时，继承方案会产生大量的子类，而组合可以提前写好处理函数，在需要时动态构造，显然是更灵活的。
+
+## 结构图
+
+<img width=600 src="https://img.alicdn.com/tfs/TB1cmhe3FY7gK0jSZKzXXaikpXa-1624-688.png">
+
+`ConcreteComponent` 指的是需要被装饰的组件，可以看到，装饰器 `Decorator` 与他都继承同一个类，这样能保证 API 的一致，才保证无论装饰多少层，始终符合 `Component` 类型。
+
+装饰器如果有多种，就要将 `Decorator` 申明为抽象类，`ConcreteDecoratorA`、`ConcreteDecoratorB` 分别实现它们，如果只有一种装饰器，可以退化到 `Decorator` 自身就是一种实现。
+
+## 代码例子
+
+下面例子使用 typescript 编写。
+
+```typescript
+class Component {
+  // 具有点击事件
+  public onClick = () => {}
+}
+
+class Decorator extends Component {
+  private _component
+
+  constructor(component) {
+    this._component = component
+  }
+
+  public onClick = () => {
+    log('打点')
+    this._component.onClick()
+  }
+}
+
+const component = new Component()
+// 一个普通的点击
+component.onClick()
+
+const wrapperComponent = new Decorator(component)
+// 一个具有打点功能的点击
+wrapperComponent.onClick()
+```
+
+其实方法很简单，通过组合，我们得到了一个能力更强的组件，而实现的方式就是利用构造函数保存组件实例，并在复写函数时，增加一些增强实现。
+
+## 弊端
+
+装饰器的问题也是组合的问题，过多的组合会导致：
+
+- 组合过程的复杂，要生成过多的对象。
+- 包装器层次增多，会增加调试成本，我们比较难追溯到一个 bug 是在哪一层包装导致的。
+
+## 总结
+
+装饰器模式是非常常用的模式，Decorator 是一个透明的包装，只要保证包装的透明性，就可以最大限度发挥装饰器模式的优势。
+
+最后总结一个装饰器应用图：
+
+<img width=500 src="https://img.alicdn.com/tfs/TB1wlpgqPMZ7e4jSZFOXXX7epXa-1232-478.png">
+
+> 讨论地址是：[精读《设计模式 - Decorator 装饰器模式》· Issue #286 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/286)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

176.精读《设计模式 - Facade 外观模式》.md

@@ -0,0 +1,99 @@
+# Facade（外观模式）
+
+Facade（外观模式）属于结构型模式，是一种日常开发中经常被使用到的设计模式。
+
+**意图：为子系统中的一组接口提供一个一致的界面，Facade 模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。**
+
+## 举例子
+
+如果看不懂上面的意图介绍，没有关系，设计模式需要在日常工作里用起来，结合例子可以加深你的理解，下面我准备了三个例子，让你体会什么场景下会用到这种设计模式。
+
+## 意图解释
+
+### 图书管理员
+
+图书馆是一个非常复杂的系统，虽然图书按照一定规则摆放，但也只有内部人员比较清楚，作为一位初次来的访客，想要快速找到一本书，最好的办法是直接问图书管理员，而不是先了解这个图书馆的设计，因为你可能要来回在各个楼宇间奔走，借书的流程可能也比较长。
+
+图书管理员就起到了简化图书馆子系统复杂度的作用，我们只要凡事询问图书管理员即可，而不需要关心他是如何与图书馆内部系统打交道的。
+
+### 最多跑一次便民服务
+
+浙江省推出的最多跑一次服务非常方便，很多办事流程都简化了，无论是证件办理还是业务受理，几乎只要跑一次，而必须要持续几天的流程也会通过手机短信或者 App 操作完成后续流程。
+
+这就相当于外观模式，因为政府系统内部的办事流程可能没有太大变化，但通过抽象出 Facade（外观），让普通市民可以直接与便民办事处连接，而不需要在车管所与驾校之间来回奔波，背后的事情没有少，只是便民办事处帮你做了。
+
+### Iphone 快捷指令功能
+
+手机的 App 非常多，而我们需要了解每个功能在哪个 App 上才能运用自如，而快捷指令功能可以将 App 的某些功能单独提取出来，形成一套新的功能组，我们可以只接触到 “拍照” “付款” “计算”，而不用管背后是调用了支付宝还是微信、系统内置摄像机还是其他摄像 App，也不用关心这个 App 内部功能的入口在哪里，这些对接都在快接指令中自动完成。
+
+快捷指令也是一种外观模式。
+
+## 意图解释
+
+**意图：为子系统中的一组接口提供一个一致的界面，Facade 模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。**
+
+为降低一个拥有多个接口的子系统内部复杂性，我们需要一个外观来屏蔽内部的复杂性，因此外观模式就是定义一个高层接口，这个接口直连子系统的内部实现，但调用这个高层接口的人不需要关心子系统内部的实现，这样，对于不想了解子系统内部实现的人来说，提高了易用度。
+
+当然如果想要深度定制，就可以绕过外观模式，直接使用子系统提供的类，所以说并不是有了外观模式就必须通过外观调用，而是根据实际需要判断使用哪种调用方式。
+
+## 结构图
+
+<img width=600 src="https://img.alicdn.com/tfs/TB1j9gZ3.T1gK0jSZFrXXcNCXXa-1082-412.png">
+
+可以看到，Facade 直接指向子系统中的类，**而子系统的类不会反向指向 Facade**。
+
+## 代码例子
+
+下面例子使用 typescript 编写。
+
+```typescript
+// 假设一个子系统是三个类结合使用的，为了抽象而解耦开了
+class A {
+  constructor(b: B) {
+    this.b = b
+  }
+}
+
+class B {
+  constructor(c: C) {
+    this.c = c
+  }
+}
+
+class C {
+  
+}
+
+// 它们组合成了一种常用功能，我们可以使用外观模式屏蔽子类的细节直接使用
+class Compile {
+  public run() {
+    const parser = new A(new B(new C))
+    parser.run()
+  }
+}
+
+const compile = new Compile()
+compile.run()
+```
+
+这样我们只要知道 `Compile` 类就可以了，而不需要了解背后的 `A` `B` `C` 以及其组合关系。
+
+## 弊端
+
+外观模式并不适合于所有场景，当子系统足够易用时，再使用外观模式就是画蛇添足。
+
+另外，当系统难以抽象出通用功能时，外观模式的设计可能也无所适从，因为设计的高层接口可能适用范围很窄，此时外观模式的意义就比较小。
+
+## 总结
+
+其实抽象工厂模式也可以代替外观模式，来实现隐藏子类具体实现的效果，但外观模式描述更具有通用性。
+
+> 讨论地址是：[精读《设计模式 - Facade 外观模式》· Issue #288 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/288)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

177.精读《设计模式 - Flyweight 享元模式》.md

@@ -0,0 +1,110 @@
+# Flyweight（享元模式）
+
+Flyweight（享元模式）属于结构型模式，是一种共享对象的设计模式。
+
+**意图：运用共享技术有效地支持大量细粒度的对象。**
+
+## 举例子
+
+如果看不懂上面的意图介绍，没有关系，设计模式需要在日常工作里用起来，结合例子可以加深你的理解，下面我准备了三个例子，让你体会什么场景下会用到这种设计模式。
+
+### 富文本编辑器的字母对象
+
+富文本编辑器在英文环境下，其中的文本由大量字母组成，为了便于做统一的格式化、计算等处理，需要将每个字母都存储为对象，但这样存储的代价太大了。
+
+已知英文字母一共 26 个，所以文档中存在大量重复使用的字母，而每个字母除了位置信息外，其它信息都是相同且只读的，那么有办法降低富文本场景巨大的字母对象数量吗？
+
+### 网盘存储
+
+当我们上传一部电影时，有时候几十 GB 的内容不到一秒就上传完了，这是网盘提示你，“已采用极速技术秒传”，你会不会心生疑惑，这么厉害的技术为什么不能每次都生效？
+
+另外，网盘存储时，同一部电影可能都会存放在不同用户的不同文件夹中，而且电影文件又特别巨大，和富文本类似，电影文件也只有存放位置是不同的，而其余内容都特别巨大且只读，有什么办法能优化存储呢？
+
+### 大型多人游戏
+
+玩多人游戏时，为了防止外挂，一般对象的创建与计算是在服务器完成的，那如何保证一个玩家拾取物品后，另一个玩家看到的物品会消失？
+
+其实道理已经不言而喻了，虽然在不同客户端之间，游戏对象是相互独立的，但在一局游戏中，所有玩家的对象在服务器是共享的。
+
+## 意图解释
+
+“共享” 就是享元模式的精髓，将那些大量的，具有很多内部状态而外部状态很少的对象进行共享，就是享元模式的使用方式。
+
+**意图：运用共享技术有效地支持大量细粒度的对象。**
+
+共享技术可以理解为缓存，当一个对象创建后，再次访问相同对象时，就不再创建新的对象了，而只有在访问没有被缓存过的对象时，才创建新对象，并立即缓存起来。
+
+这样做可以有效支持大量细粒度的对象，在富文本例子中，**无数的字母就是大量细粒度对象**，在网盘存储中，**电影文件就是大量细粒度对象**，在大型多人游戏中，**每局游戏内存在大量细粒度对象**。
+
+这些细粒度对象都拥有相同的特征：
+
+- 量特别大，这个很容易理解。
+- 具有大量内部状态，且不随着客户端的不同而改变。
+  - 富文本的字母，不因为展示到不同语句中而发生变化，变化的只有状态；电影文件，不因为放在不同用户的文件夹中而对电影内容产生变化，变化的只有属于哪些用户，放在哪些文件夹里；多人游戏中，同一把武器对象，不因为有多个人的电脑独立运行而拥有更多的弹药，变化的只有在哪些客户端被访问。
+- 具有少量外部状态，甚至没有外部状态。在上面已经解释了，字母的位置、电影的位置、游戏对象的客户端都是外部状态，这些外部状态相比于其内部状态来说，大小微乎其微，且方便分离存储。
+
+遇到这种情况，我们就可以将对象内部状态共享，外部状态独立存储，从而节省大量空间。
+
+尤其是对于网盘的场景，承诺给用户 2 TB 的存储空间，这个用户看到其他人分享了 100 个电影，就点击 “下载到我的网盘”，**此时虽然占用了自己 1 TB 的网盘空间，但实际上网盘运营商并没有增加 1 TB 的存储空间，实际可能增加了 1kb 的存储空间，记录了存储位置**，这就是网盘鸡贼的地方，并不占用空间的内容，却占用了用户真金白银购买的存储空间。
+
+当然，这就是享元模式的价值，对网盘公司来说，价值巨大，对用户来说，没有价值。所以享元模式的价值体现在全局，比如对整个富文本编辑器来说，减少了巨量字母对象数量，但对于每一个字母对象而言，并没有任何优化。
+
+## 结构图
+
+<img width=800 src="https://img.alicdn.com/tfs/TB1KMTY4UY1gK0jSZFMXXaWcVXa-1420-886.png">
+
+对于 Client 而言，下图描述了如何共享 Flyweight：
+
+<img width=800 src="https://img.alicdn.com/tfs/TB1JwLL4QL0gK0jSZFtXXXQCXXa-1460-542.png">
+
+- Flyweight: 共享接口，通过这个接口可以操作对象的外部状态。
+- ConcreteFlyweight: 实现 Flyweight 接口的对象，这个对象是可被共享的。
+- UnsharedConcreteFlyweight: 不被共享的对象，因为在享元模式中，实际上并不是所有对象都可以被共享。
+- FlyweightFactory: 创建并管理 Flyweight 对象，通过其返回的 Flyweight 对象，如果已创建，则会返回之前创建的那个，没有的话才会创建一个新的。
+- Client: 使用 Flyweight 的客户端。
+
+通过第二个图可以明显看到，两个不同的 Client 持有了相同 `aConcreteFlyweight` 引用。
+
+## 代码例子
+
+下面例子使用 typescript 编写。
+
+```typescript
+class FlyweightFactory {
+  public getFlyWeight(key) {
+    if (this.flyweight[key]) {
+      return this.flyweight[key]
+    }
+
+    const flyweight = new Flyweight()
+    this.flyweight[key] = flyweight
+    return flyweight
+  }
+}
+```
+
+`FlyweightFactory` 提供的 `getFlyWeight` 方法，实际上是按照 `key` 对 `flyweight` 实例进行缓存，相同 `key` 下只存储一个 `flyweight` 实例。
+
+## 弊端
+
+如果细粒度对象不多，则没必要使用享元模式。
+
+另外，就算细粒度对象很多，如果对象内部状态并不多，主要都是外部状态，那么享元模式就起不到什么作用了，**因为享元模式通过共享对象，只能节省内部状态，而不能节省外部状态。**
+
+另外，如果享元模式映射到的共享对象数量并没有比原始对象少出数量级关系，使用的意义也不大。比如富文本编辑器的例子，对于英文来说，一共就 26 个字母，那么 1 万字的文章优化比例是 10000:26，但对于中文文章而言，文字实例本身就很多，可能 1 万字的文章中，汉字去重后依然有 3000 个，那么优化比例就是 10000:3000，此时享元模式的意义就没那么打了。
+
+## 总结
+
+享元模式的本质就是尽可能的共享对象，特别适用于存在大量细粒度对象，而这些对象内部状态特别多，外部状态较少的场景。
+
+对于云存储来说，享元模式是必须使用的，因为云存储的场景决定了，存在大量细粒度文件对象，而存在大量只读的文件，就非常适合共享一个对象，每个用户存储的只是引用。
+
+> 讨论地址是：[精读《设计模式 - Flyweight 享元模式》· Issue #290 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/290)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

178.精读《设计模式 - Proxy 代理模式》.md

@@ -0,0 +1,100 @@
+# Proxy（代理模式）
+
+Proxy（代理模式）属于结构型模式，通过访问代理对象代替访问原始对象，以获得一些设计上的便捷。
+
+**意图：为其他对象提供一种代理以控制这个对象的访问。**
+
+## 举例子
+
+如果看不懂上面的意图介绍，没有关系，设计模式需要在日常工作里用起来，结合例子可以加深你的理解，下面我准备了三个例子，让你体会什么场景下会用到这种设计模式。
+
+### 获得文本对象长度
+
+获得一个文本对象长度，必须要真正渲染出来，而渲染是比较耗时的，我们可能只在某些场景下需要访问文本对象长度，而更多时候只需要读取文本内容，这两种操作耗时是完全不同的，如何做到业务层调用无感知，来优化执行耗时呢？
+
+代理模式可以解决这个问题，我们将业务层使用的文本对象替换为代理对象，这个代理对象初始化并不渲染文本，而是在调用文本长度时才渲染。
+
+### 对象访问保护
+
+某个大型系统开发完了，突然要求增加代码访问权限体系，不同模块对相同的底层对象拥有不同访问权限，此时这个权限控制逻辑如果写入底层对象，就违背了开闭原则，而对象本身的实现也不再纯粹，增加了维护成本，如何做到不修改对象本身，实现权限控制呢？
+
+代理模式也能解决，将底层对象导出替换为代理对象，由代理对象控制访问权限即可。
+
+### 对象与视图双向绑定
+
+Angular 或 Vue 这类前端框架采用双向绑定视图更新技术，即对象修改后，使用到的视图会自动刷新，这就需要做到以下两点：
+
+1. 在对象被访问时，记录调用的视图绑定。
+2. 在对象被修改时，刷新调用它的视图。
+
+问题是，在业务代码使用对象与修改对象的地方插入这段逻辑，显然会增加巨大的维护成本，如何做到业务层无感知呢？
+
+代理模式可以很好的解决这个问题，其实业务层拿到的对象已经是代理对象了，它在被访问与被修改时，都会执行固定的钩子做视图绑定与视图刷新。
+
+## 意图解释
+
+**意图：为其他对象提供一种代理以控制这个对象的访问。**
+
+代理模式的意图很容易理解，就是通过代理对象代替原始对象的访问。
+
+这只是代理模式的实现方式，代理模式真正的难点不在于理解它是如何工作的，而是理解哪些场景适合用代理，或者说创建了代理对象，怎么用才能发挥它的价值。
+
+在上面例子中，已经举出了几种常见代理使用场景：
+
+1. 对开销大的对象使用代理，以按需使用。
+2. 对需要保护的对象进行代理，在代理层做权限控制。
+3. 在对象访问与修改时要执行一些其他逻辑，适合在代理层做。
+
+## 结构图
+
+<img width=600 src="https://img.alicdn.com/imgextra/i3/O1CN01eZHGHQ28t0oeHYzas_!!6000000007989-2-tps-1262-522.png">
+
+使用时关系如下：
+
+<img width=600 src="https://img.alicdn.com/imgextra/i4/O1CN01iwyMKQ1KbOnR0N2AP_!!6000000001182-2-tps-1270-206.png">
+
+Subject 定义的是 RealSubject 与 Proxy 共用的接口，这样任何使用 RealSubject 的地方都可以使用 Proxy。
+
+RealSubject 指的是原始对象，Proxy 是一个代理实体。
+
+关系图中可以看出，当客户端要访问 subject 时，第一层访问的是 Proxy 代理，由这个代理将 realSubject 转发给客户端。
+
+## 代码例子
+
+下面例子使用 typescript 编写。
+
+```typescript
+// 对象 obj
+const proxy = new Proxy(obj, {
+  get(target,key) {}
+  set(target,key,value) {}
+})
+```
+
+JS 创建代理还是蛮简单的，代理可以控制对象的所有成员属性，包括成员变量与成员方法的访问（get）与修改（set）。
+
+## 弊端
+
+代理模式会增加微弱的开销，因此请不要将所有对象都变成代理，没有意义的代理只会徒增程序开销。
+
+另外代理对象过多，也会导致调试困难，因为代理层的存在，我们往往可能忽略这一层带来的影响，导致忘记这个对象其实是一个代理。
+
+## 总结
+
+代理和继承有足够多的相似之处，继承中，子类几乎可以人为是对父类的代理，子类可以重写父类的方法。但代理和继承还是有区别的：
+
+如果你没有采用 `new Proxy` 这种 API 创建代理，而是采用继承的方式实现，你会一下子继承这个类的所有方法，而做不到按需控制访问权限的灵活效果，所以代理比继承更加灵活。
+
+JS 的 `new Proxy` 对应了 Java 动态代理模式，一般认为动态代理比静态代理更强大。
+
+最后，还要重申那句话，代理模式理解与运用并不难，难就难在能否在恰当的场合想到它，双向绑定几乎是代理模式最好的例子。
+
+> 讨论地址是：[精读《设计模式 - Proxy 代理模式》· Issue #291 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/291)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）