前端的设计模式（列举9种

设计模式

结构型模式

1. 外观模式：为子系统中的一组接口提供一个统一的高层接口，使子系统更容易使用。

2. 代理模式：如ES6的Proxy。

   解决以下问题：

   1. 增加对一个对象的访问控制
   2. 当访问一个对象的过程中需要增加额外的逻辑

   实现需要的条件：

   1. 真实对象
   2. 代理对象
   3. 接口

3. 创建型模式

   1. 工厂模式：制造其他对象的对象，随着传入工厂对象参数的不同有所区别。提供一种集中化、统一化的方式，避免了分散创建对象导致的代码重复、灵活性差的问题。

      用处：构造函数过多，不方便管理，且需要创建的对象之间存在某些关联。

   2. 单例模式：class的实例个数最多为1。当需要一个对象去贯穿整个系统执行某些任务的时候，用单例模式。

      需要注意：除了以上这种使用场景外，尽量避免单例模式的使用，因为单例模式会引入全局状态，而系统应该避免引用过多的全局状态。

      解决以下问题：

      1. 确定class只有一个实例
      2. 简便的访问class的唯一实例
      3. class控制实例化过程
      4. 将class的实例个数限制为1

      解决问题的方法：

      1. 隐藏class的构造函数，避免多次实例化
      2. 通过暴露一个getInstance()方法来创建/获取唯一的实例

      实现的关键点：

      1. 使用IIFE创建局部作用域并立即执行
      2. getInstance()作为一个闭包，使用闭包保存局部作用域中的单例对象并返回

4. 行为型模式

   1. 策略模式：对象有某个行为，但是在不同的场景中，该行为有不同的实现算法。

      优势：

      1. 方便在运行时切换算法和策略
      2. 代码更简洁，避免使用大量的条件判断
      3. 关注分离，每个strategy类控制自己的算法逻辑，strategy和其使用者之间也互相独立

   2. 迭代器模式：迭代器用于遍历容器（集合）并访问容器中的元素，无论容器的数据结构是什么，迭代器的接口都应该是一样的，都需要遵循迭代器协议。

      解决以下问题：

      1. 提供一致的遍历各种数据结构的方式，而不用了解数据的内部结构
      2. 提供遍历容器的能力而无需改变容器的接口

      迭代器需要实现：

      1. hasNext()判断迭代是否结束，并返回Boolean
      2. next()查找并返回下一个元素

   3. **观察者模式（发布订阅模式）：**被观察对象维护一组观察者，当被观察对象状态改变时，通过观察者的某个方法将这些变化通知到观察者。

      一般需要实现以下功能:

      1. subscribe()：接收一个观察者observer对象，使其订阅自己
      2. unsubscribe()：接收一个观察者observer对象，使其取消订阅自己
      3. fire()：触发事件，通知到所有观察者

   4. 中介者模式：中介者包装了一系列对象项目作用的方式，使得这些对象不必直接相互作用，而是由中介者协调他们的交互，使他们可以松散耦合。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用，保证这些作用可以彼此独立的变化。

   5. 访问者模式：访问者模式让我们能够在不改变一个对象结构的前提下能够给该对象增加新的逻辑，新增的逻辑保存在一个独立的访问者对象中。访问者模式通常用于扩展一些第三方库和工具。

      实现的要素：

      1. Visitor Object：访问者对象，拥有一个 visit() 方法
      2. Receiving Object：接收对象，拥有一个 accept() 方法
      3. visit(receivingObj)：用于Visitor接收一个Receiving Object
      4. accept(visitor)：用于Receving Object接收一个Visitor，并通过调用Visitor的 visit() 为其提供获取Receiving Object数据的能力

本文完全参考思否上：参考链接，配有示例代码，写的特别清楚。

个人总结感悟：

​ 设计模式无非就是在写代码过程中，对于某类问题的通用解决方案，主要是理解解决思想，减少冗余代码。