作者：Jake Zhang

转发链接：https://juejin.im/post/5ef8377f6fb9a07e693a6061

63. instanceof的原理是什么，如何实现

instanceof 可以正确的判断对象的类型，因为内部机制是通过判断对象的原型链中是不是能找到类型的 prototype。

实现 instanceof：

首先获取类型的原型然后获得对象的原型然后一直循环判断对象的原型是否等于类型的原型，直到对象原型为 null，因为原型链最终为 null

function myInstanceof(left, right) { let prototype = right.prototype left = left.__proto__ while (true) { if (left === null || left === undefined) return false if (prototype === left) return true left = left.__proto__ } }

64. js 的节流与防抖

函数防抖 是指在时间被触发 n 秒后再执行回调，如果在这 n 秒内时间又被触发，则重新计时。这可以使用在一些点击请求的时间上，避免因为用户的多次点击向后端发送多次请求。

函数节流 是指规定一个单位时间，在这个单位时间内，只能有一次触发时间的回调函数执行，如果在同一个单位时间内某时间被触发多次，只有一次能生效。节流可以使用在 scroll 函数的事件监听上，通过事件节流来降低事件调用的频率。

// 函数防抖的实现 function debounce(fn, wait) { var timer = null; return function() { var context = this, args = arguments; // 如果此时存在定时器的话，则取消之前的定时器重新记时 if (timer) { clearTimeout(timer); timer = null; } // 设置定时器，使事件间隔指定事件后执行 timer = setTimeout(() => { fn.apply(context, args); }, wait); }; } // 函数节流的实现; function throttle(fn, delay) { var preTime = Date.now(); return function() { var context = this, args = arguments, nowTime = Date.now(); // 如果两次时间间隔超过了指定时间，则执行函数。 if (nowTime - preTime >= delay) { preTime = Date.now(); return fn.apply(context, args); } }; }

详细资料可以参考：

《轻松理解 JS 函数节流和函数防抖》https://juejin.im/post/5a35ed25f265da431d3cc1b1

《JavaScript 事件节流和事件防抖》https://juejin.im/post/5aa60b0e518825556b6c6d1a

《JS 的防抖与节流》https://juejin.im/entry/5b1d2d54f265da6e2545bfa4

65. 什么是设计模式？

1. 概念

设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。

2. 设计原则

S – Single Responsibility Principle 单一职责原则 一个程序只做好一件事如果功能过于复杂就拆分开，每个部分保持独立 O – OpenClosed Principle 开放/封闭原则 对扩展开放，对修改封闭增加需求时，扩展新代码，而非修改已有代码 L – Liskov Substitution Principle 里氏替换原则 人类能覆盖父类父类能出现的地方子类就能出现 I – Interface Segregation Principle 接口隔离原则 保持接口的单一独立类似单一职责原则，这里更关注接口 D – Dependency Inversion Principle 依赖倒转原则 面向接口编程，依赖于抽象而不依赖于具使用方只关注接口而不关注具体类的实现

3. 设计模式的类型

结构型模式（Structural Patterns）： 通过识别系统中组件间的简单关系来简化系统的设计。 创建型模式（Creational Patterns）： 处理对象的创建，根据实际情况使用合适的方式创建对象。常规的对象创建方式可能会导致设计上的问题，或增加设计的复杂度。创建型模式通过以某种方式控制对象的创建来解决问题。 行为型模式（Behavioral Patterns）： 用于识别对象之间常见的交互模式并加以实现，如此，增加了这些交互的灵活性。

66. 9种前端常见的设计模式

1. 外观模式（Facade Pattern）

外观模式是最常见的设计模式之一，它为子系统中的一组接口提供一个统一的高层接口，使子系统更容易使用。简而言之外观设计模式就是把多个子系统中复杂逻辑进行抽象，从而提供一个更统一、更简洁、更易用的API。很多我们常用的框架和库基本都遵循了外观设计模式，比如JQuery就把复杂的原生DOM操作进行了抽象和封装，并消除了浏览器之间的兼容问题，从而提供了一个更高级更易用的版本。其实在平时工作中我们也会经常用到外观模式进行开发，只是我们不自知而已。

兼容浏览器事件绑定

let addMyEvent = function (el, ev, fn) { if (el.addEventListener) { el.addEventListener(ev, fn, false) } else if (el.attachEvent) { el.attachEvent('on' + ev, fn) } else { el['on' + ev] = fn } };

封装接口 let myEvent = { // ... stop: e => { e.stopPropagation(); e.preventDefault(); } };

场景

设计初期，应该要有意识地将不同的两个层分离，比如经典的三层结构，在数据访问层和业务逻辑层、业务逻辑层和表示层之间创建外观Facade 在开发阶段，子系统往往因为不断的重构演化而变得越来越复杂，增加外观Facade可以提供一个简单的接口，减少他们之间的依赖。在维护一个遗留的大型系统时，可能这个系统已经很难维护了，这时候使用外观Facade也是非常合适的，为新系统开发一个外观Facade类，为设计粗糙和高度复杂的遗留代码提供比较清晰的接口，让新系统和Facade对象交互，Facade与遗留代码交互所有的复杂工作。

优点

减少系统相互依赖。提高灵活性。提高了安全性

缺点

不符合开闭原则，如果要改东西很麻烦，继承重写都不合适。

2. 代理模式（Proxy Pattern）

是为一个对象提供一个代用品或占位符，以便控制对它的访问

假设当A 在心情好的时候收到花，小明表白成功的几率有60%，而当A 在心情差的时候收到花，小明表白的成功率无限趋近于0。小明跟A 刚刚认识两天，还无法辨别A 什么时候心情好。如果不合时宜地把花送给A，花被直接扔掉的可能性很大，这束花可是小明吃了7 天泡面换来的。但是A 的朋友B 却很了解A，所以小明只管把花交给B，B 会监听A 的心情变化，然后选择A 心情好的时候把花转交给A，代码如下：

let Flower = function() {} let xiaoming = { sendFlower: function(target) { let flower = new Flower() target.receiveFlower(flower) } } let B = { receiveFlower: function(flower) { A.listenGoodMood(function() { A.receiveFlower(flower) }) } } let A = { receiveFlower: function(flower) { console.log('收到花'+ flower) }, listenGoodMood: function(fn) { setTimeout(function() { fn() }, 1000) } } xiaoming.sendFlower(B)

场景

HTML元素事件代理

<ul id="ul"> <li>1</li> <li>2</li> <li>3</li> </ul> <script> let ul = document.querySelector('#ul'); ul.addEventListener('click', event => { console.log(event.target); }); </script>

ES6 的 proxy 阮一峰Proxy jQuery.proxy()方法

优点

代理模式能将代理对象与被调用对象分离，降低了系统的耦合度。代理模式在客户端和目标对象之间起到一个中介作用，这样可以起到保护目标对象的作用代理对象可以扩展目标对象的功能；通过修改代理对象就可以了，符合开闭原则；

缺点

处理请求速度可能有差别，非直接访问存在开销

3. 工厂模式（Factory Pattern）

工厂模式定义一个用于创建对象的接口，这个接口由子类决定实例化哪一个类。该模式使一个类的实例化延迟到了子类。而子类可以重写接口方法以便创建的时候指定自己的对象类型。

class Product { constructor(name) { this.name = name } init() { console.log('init') } fun() { console.log('fun') } } class Factory { create(name) { return new Product(name) } } // use let factory = new Factory() let p = factory.create('p1') p.init() p.fun()

场景

如果你不想让某个子系统与较大的那个对象之间形成强耦合，而是想运行时从许多子系统中进行挑选的话，那么工厂模式是一个理想的选择将new操作简单封装，遇到new的时候就应该考虑是否用工厂模式；需要依赖具体环境创建不同实例，这些实例都有相同的行为,这时候我们可以使用工厂模式，简化实现的过程，同时也可以减少每种对象所需的代码量，有利于消除对象间的耦合，提供更大的灵活性

优点

创建对象的过程可能很复杂，但我们只需要关心创建结果。构造函数和创建者分离, 符合“开闭原则” 一个调用者想创建一个对象，只要知道其名称就可以了。扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。

缺点

添加新产品时，需要编写新的具体产品类,一定程度上增加了系统的复杂度考虑到系统的可扩展性，需要引入抽象层，在客户端代码中均使用抽象层进行定义，增加了系统的抽象性和理解难度

什么时候不用

当被应用到错误的问题类型上时,这一模式会给应用程序引入大量不必要的复杂性.除非为创建对象提供一个接口是我们编写的库或者框架的一个设计上目标,否则我会建议使用明确的构造器,以避免不必要的开销。由于对象的创建过程被高效的抽象在一个接口后面的事实,这也会给依赖于这个过程可能会有多复杂的单元测试带来问题。

4. 单例模式（Singleton Pattern）

顾名思义，单例模式中Class的实例个数最多为1。当需要一个对象去贯穿整个系统执行某些任务时，单例模式就派上了用场。而除此之外的场景尽量避免单例模式的使用，因为单例模式会引入全局状态，而一个健康的系统应该避免引入过多的全局状态。

实现单例模式需要解决以下几个问题：

如何确定Class只有一个实例？如何简便的访问Class的唯一实例？ Class如何控制实例化的过程？如何将Class的实例个数限制为1？

我们一般通过实现以下两点来解决上述问题：

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

Javascript中单例模式可以通过以下方式实现：

// 单例构造器 const FooServiceSingleton = (function () { // 隐藏的Class的构造函数 function FooService() {} // 未初始化的单例对象 let fooService; return { // 创建/获取单例对象的函数 getInstance: function () { if (!fooService) { fooService = new FooService(); } return fooService; } } })();

实现的关键点有：

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

我们可以验证下单例对象是否创建成功：

const fooService1 = FooServiceSingleton.getInstance(); const fooService2 = FooServiceSingleton.getInstance(); console.log(fooService1 === fooService2); // true

场景例子

定义命名空间和实现分支型方法登录框 vuex 和 redux中的store

优点

划分命名空间，减少全局变量增强模块性，把自己的代码组织在一个全局变量名下，放在单一位置，便于维护且只会实例化一次。简化了代码的调试和维护

缺点

由于单例模式提供的是一种单点访问，所以它有可能导致模块间的强耦合从而不利于单元测试。无法单独测试一个调用了来自单例的方法的类，而只能把它与那个单例作为一个单元一起测试。