使人拍案叫绝的四种设计模式！

0. 回顾过去

说实话，这标题有点儿 uc小编 的味道了。虽然真正的大佬已经对设计模式烂熟于胸，只但愿个人学习记录能帮助到部分同窗就足够了。通过我下面的介绍，你能够在极短的时间，了解并知道如何使用他们。

通过一两个月的分享断断续续的，我一共分享了 11 种 Javascript 设计模式，其中：

• 工厂模式，单例模式，适配器模式，装饰者模式，建造者模式 过去看看
• 构造函数模式，外观模式，代理模式 用英雄联盟的方式讲解JavaScript设计模式！
• 策略模式，桥接模式，状态模式 过去看看

每一种设计模式都是前辈们总结多年的经验，实属精华。尽管我不能彻底出神入化的运用它，但在一个程序但设计上，必定会或多或少的来借鉴他们的思想。自从学习了设计模式，在写代码的时候，终于不会气喘吁吁，一口气写五个组件，不费劲。

「那下面，接着介绍四种，使人拍案叫绝的！设计模式。」

1. 原型模式

简介

原型模式（prototype）是指用原型实例指向建立对象的种类，而且经过拷贝这些原型建立新的对象。

「说实话，每次一看设计模式的简介就头大，明明每一个字都认识，结合起来就懵了。和我同样状况的小伙伴，建议直接看代码，有的时候...看看注释，看看设计模式的名字，也许就豁然开朗！」

实际操做

原型模式的使用可让咱们获得，原始对象附带的一些属性，以下：

var lol = {
 server: '比尔吉沃特',  startGame: function () {  console.log('link start!')  } };  // 经过原型模式，新建同一个服务器的新用户 var User = Object.create(lol, {  'name': {  value: '黄梵高'  } });  复制代码

上面能够说就是一个完整的原型模式。把原有对象内包含的属性，经过Object.create函数，成功拷贝。而且在建立新对象时，添加进入新增的name字段，十分人性化。

若是说你以为，哦，我这要兼容 ie8 的，用不来Object.create这种高级浏览器才支持的函数。那彻底能够的，下面再来介绍不使用这函数的原型模式实现：

var lol = {
 server: '比尔吉沃特',  startGame: function () {  console.log('link start!')  },  init: function (name) { // 须要增长一个接口，用于修改内部属性  this.name = name  }, };   function User(name) {  function F() { };  F.prototype = lol;   var f = new F();  f.init(name);  return f; }  var user = User('黄梵高'); user.startGame(); // user.server 复制代码

这种原型模式的实现方式，和上面的Object.create方式略有不一样，由于建立了一个名叫F的构造函数，而且提早暴漏了接口init才得以修改内部属性，和直接建立对象相比天然是冗余了很多。

不过相信兼容 ie8 的需求也仍是存在的，不少时候仍是不得不使用它啊！

那恭喜你学会了原型模式，由于十分简单，平时开发也会不经意间用到，但要注意浅拷贝和深拷贝的问题哦。先来道开胃菜，这波啊这波是一道肉蛋葱鸡。

2. 观察者模式

介绍

观察者模式又叫发布订阅模式（Publish/Subscribe），它定义了一种一对多的关系，让多个观察者对象同时监听某一个主题对象，这个主题对象的状态发生变化时就会通知全部的观察者对象，使得它们可以自动更新本身。

实践环节

其实观察者模式，真的太熟悉了。就是当你开源项目终于发布了，你但愿不少人都知道，但不能你一个一个去告诉吧，那也太卑微了。因此最好的方式是你有一群粉丝，他们翘首以盼着等着你的开源项目，终于你在b站，开了一个发布会。不少粉丝争先恐后地去听，听完以后回家根据这个新框架开始练手。这就构成了一个观察者模式。

观察者的使用场合就是：当一个对象的改变须要同时改变其它对象，而且它不知道具体有多少对象须要改变的时候，就应该考虑使用观察者模式。

先来一个十分简陋的模式例子：

var timer = setInterval(() => {  if (window.good) {  clearInterval(timer)  console.log('good了')  } }, 500)  setTimeout(() => {  window.good = 1 }, 2000)  复制代码

• s: 实现成功！教练我学会了！这边疯狂修改全局变量，另外一边疯狂event loop就行了，500毫秒延迟过高了，我再低一点，调个50吧，再来一个 for 循环，遍历建立事件就能够了！

• t: 且不说性能问题，那若是页面不少，你在某一个页面抛出的变量必定能接的到吗？或者会不会有变量冲突，多人维护的时候怎么能保证全局变量的统一处理？

• s: 那教练我不会了。

• t: 下面教练教你一招，经过存放回调函数的方式队列执行：

var pubsub = {};
(function (q) {  var topics = {}, // 回调函数存放的数组，把全部的  subUid = -1;  // 发布方法  q.publish = function (topic, args) {  if (!topics[topic]) {  return false;  }  setTimeout(function () {  var subscribers = topics[topic], // 名字为topic变量的事件队列  len = subscribers ? subscribers.length : 0;  while (len--) {  subscribers[len].func(topic, args); // 循环执行传进来的函数  }  }, 0); // 使用setTimeout保证先执行完同步代码逻辑  return true;  };  //订阅方法  q.subscribe = function (topic, func) {  if (!topics[topic]) {  topics[topic] = [];  }  var token = (++subUid).toString();  topics[topic].push({  token: token,  func: func  });  return token;  };  //退订方法  q.unsubscribe = function (token) {  for (var m in topics) { // 先找到要退订的事件队列  if (topics[m]) {  for (var i = 0, j = topics[m].length; i < j; i++) { // 传进来的token，是在触发订阅函数时生成的token  if (topics[m][i].token === token) { // 找到专属token，进行队列删除操做  topics[m].splice(i, 1);  return token;  }  }  }  }  return false;  }; } (pubsub));  //将订阅赋值给一个变量，以便退订 var sub = pubsub.subscribe('lol', function (topics, data) {  console.log(topics + ": " + data); });  //发布通知 pubsub.publish('lol', 'hello world!'); pubsub.publish('lol', ['test', 'a', 'b', 'c']); pubsub.publish('lol', [{ 'color': 'blue' }, { 'text': 'hello'}]);  setTimeout(function () {  pubsub.unsubscribe(sub); }, 0);  pubsub.publish('lol', 'hello world!'); // 不会再执行订阅时传入的函数了  复制代码

以上就实现了一个，以事件回调为基础的观察者模式模型。拥有订阅，发布，退订操做。「能够知足大部分对于一个对象的改变须要同时改变其它对象，而且它不知道具体有多少对象须要改变」的状况。

经过事件队列依次执行，若是须要加强函数功能，只须要扩展函数便可。

另一个观察者显而易见的例子：若是你平时使用 vue React 等框架的话，里面的 redux vuex 就涉及到观察者模式。

小结

可是，观察者虽好，可不要贪杯嗷。为何这么说呢？

1. 一个观察者模式的实现，不免须要很长的逻辑，不免影响一些内存
2. 若是在被观察者之间有循环依赖的话，被观察者会触发它们之间进行循环调用，致使系统崩溃。在使用观察者模式是要特别注意这一点。
3. 观察者模式可使观察者知道所观察的对象发生了变化，但观察者模式没有使观察者知道所观察的对象是怎么发生变化的。
4. 观察者模式让一个本能够不触发的事件，一直停留在内存中，即便事件不会执行。
5. 弱化了对象之间的联系，会致使项目的难以跟踪维护和理解。

只要不滥用，观察者模式仍是可以让逻辑分离，实现代码解耦，提升可维护程度。总比用setInterval来循环监听全局变量要好得多吧。

3. 迭代器模式

简介

迭代器模式(Iterator)：提供一种方法顺序一个聚合对象中各个元素，而又不暴露该对象内部表示。

其实就是在不暴露对象的状况，能够拿到全部对象内的 元素。

其实ES6设计了Iterator的概念

下面是阮大官网介绍的栗子

实际操做

var it = makeIterator(['a', 'b']);
 it.next() // { value: "a", done: false } it.next() // { value: "b", done: false } it.next() // { value: undefined, done: true }  function makeIterator(array) {  var nextIndex = 0;  return {  next: function() {  return nextIndex < array.length ?  {value: array[nextIndex++], done: false} :  {value: undefined, done: true};  }  }; }  复制代码

简单看一下代码，很清晰，十分易于理解，迭代器模式要的就是不须要关心数据结构，但只要咱们调用it.next()方法，就能够知道对象全部的内容，按照顺序返回给咱们！

而咱们并不会暴露it对象里面全部的数据，十分人性化。

可是须要注意的是，在JavaScript的世界里，并不是全部对象都有迭代器，类数组，数组，字符串是拥有迭代器的，但一个普通的对象必须部署了 Iterator 接口后才能使用。

那咱们再举个栗子🌰：

var obj = {  name: 123,  age: 18,  info: [{  friend: 'abc',  title: 'ba'  }] }  //  复制代码

这样的一个对象，若是想能拿到全部对象，但不把对象暴露出来该怎么办呢？

这种状况对于前端开发能够说司空见惯了，后端给的数据必定是多层嵌套的，只要是 JavaScript 有的数据类型，确定都有机会出现，那若是但愿遍历取值怎么办？

相信Object.keys()是不少人的选择！

for (var key of Object.keys(obj)) {
 console.log(key + ': ' + obj[key]); }  //name: 123 //age: 18 //info: [object Object] 复制代码

小结

上面就实现了迭代器模式，不少人都认为迭代器模式比较简单，甚至不少语言都会内置迭代器，方便使用，更有甚者认为这不属于一种设计模式。

其实设计模式也就是前人总结的设计经验，建筑学中有着更多的设计模式，软件工程学中有着相比之下较少，但精华的模式，正由于它十分优秀，才会在多种编程语言下大放异彩，而不该由于它被内置而再也不说起。

4. 中介者模式

中介者模式，一看名字就知道，应该是有一个东西做为两端沟通的中介。好比，咱们平时租房买房，不免要和中介打交道，不少时候就被中介把买卖双方都坑了，这种时候就是个十分差劲的中介者模式实践😠！

简介

中介者模式（Mediator），用一个中介对象来封装一系列的对象交互。中介者使各对象不须要显式地相互引用，从而使其耦合松散，并且能够独立地改变它们之间的交互。

中介者模式的本质就是，有一个集权的管理控制函数，可以作到单向的接受信息并进行分发消息和动做。

与观察者模式的区别

这两种模式真的很像，因而网络上很容易的找到一段不明因此的话。

❝

观察者模式，没有封装约束的单个对象，相反，观察者Observer和具体类Subject是一块儿配合来维护约束的，沟通是经过多个观察者和多个具体类来交互的：每一个具体类一般包含多个观察者，而有时候具体类里的一个观察者也是另外一个观察者的具体类。而中介者模式所作的不是简单的分发，倒是扮演着维护这些约束的职责。

❞

这句话能够说，十分晦涩难懂...

用点清楚的白话来描述两者区别：

「观察者模式，确定会有一个观察者的列表，其中可能会有增长，删除，插入，置空等等接口函数。调用观察者函数的，能够经过这些接口，进行一些操做，也就是和原有的观察者函数，共同来维护观察者列表！」

「中介者模式特色就是：不须要调用中介者函数的，来进行一些对中介者列表对处理。由于这份列表，是中介者函数提供的，并不须要共同维护，只须要中介者函数本身来维护。而后和观察者模式一样的，拥有分发和监听对功能！」

差异也就是，具体的监听列表，能不能用调用它对函数进行维护。

实践环节

function LOL (username) {
 this.username = username  this.task = {} } LOL.prototype.on = function (type, callback) {  this.task[type].push(callback) } LOL.prototype.emit = function (type) {  this.task[type].forEach(item => {  item && item()  }) }  var mine = new LOL('黄梵高') mine.on('start', function(){  console.log('start') }) mine.emit('start') 复制代码

上面的手写代码，能够说观察者模式和中介者模式，均可以这么实现。具体区别就是观察者模式的话，实现还应该会多出unemit, empty等等函数，便于操做观察者列表。

中介者模式内部应该还会有一些其余处理，好比：

function LOL (username) {
 this.username = username  this.task = {} } LOL.prototype.on = function (type, callback) {  this.task[type].push(callback) } LOL.prototype.emit = function (type) {  if (type === 'stop') { // 若是事件为中止，则把start列表所有清空  this.task['start'] = []  }  this.task[type].forEach(item => {  item && item()  }) } 复制代码

如上注释处，中介者模式会把维护列表的工做，与本身融为一体，省着你在外面操做。

中介者模式也一样能够用，买卖租房的中介来理解。不管中介是好是坑，其实做为找中介的咱们，也没办法去改变它给咱们提供的房屋列表。

小结

中介者模式并不困难，某种程度上和观察者实现差很少。固然两者也有区别，刚才也已经叙述。请根据业务需求具体使用。

总结

设计模式能够帮助咱们设计函数结构，易于维护，开发也能够避免失误。但过分设计也会形成资源浪费，开发周期增长等缺点，因此必定要适度结合使用。在频繁改动的项目，即便你设计的十分优雅，也有可能直接被产品把功能砍掉...不管怎样抽象解耦，也必定要适度而行。好比我目前维护的项目，频繁使用观察者模式并不适合，会形成不少的资源浪费，某些状况下，甚至调整 dom 资源加载顺序也能够解决一些问题（开发时可能会有不少种不一样方案，请用性价比最高的方案！）。

参考文献

Tom大叔博客

本文使用 mdnice 排版