update

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 instance = () => {
+    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)）