理解JavaScript的核心知识点：原型

时间 2019-12-31

原文原文链接

JavaScript 中的原型机制一直以来都被众多开发者（包括本人）低估甚至忽视了，这是由于绝大多数人没有想要深入理解这个机制的内涵，以及愈来愈多的开发者缺少计算机编程相关的基础知识。对于这样的开发者来讲 JavaScript 的原型机制是一个尚待发掘的大宝藏，深刻了解下去会让你们在编程这条路上走得更长远，固然你不能妄想任何一种机制、模式或范式是天衣无缝的。javascript

首先，须要来理清一些基础的计算机编程概念：html

编程哲学与设计模式：Programming Philosophy and Design Pattern

计算机编程理念源自于对现实抽象的哲学思考，面向对象编程（OOP）是其一种思惟方式，与它并驾齐驱的是另外两种思路：过程式和函数式编程。这三种方式对应于解决计算机架构问题的三种不一样思路。它们也分别表明了不一样的编程哲学。java

具体实现编程架构的代码方案能够称为设计模式。设计模式是解决具体问题的一种最佳实践，能够用在设计语言自己，也能够用在具体业务场景中。git

三种思路在语言自己的设计和应用业务中是可能混用的，灵活的语言正如 JavaScript ，内部虽然是基于面向对象编程而实现，但在开发过程当中也能够运用过程式编程或函数式编程的思路进行具体业务的设计。正由于这容易形成开发者的混乱，因此特别指出，下面一段讨论的是针对语言内部的实现方式而不是应用业务。github

面向对象编程语言的核心是对象，针对如何设计出一套语言的对象模型编程大师们又提出了三种不一样的模式：类、原型、元类（元类是基于类模型产生的新模型）。三种模型造就了许多不一样的编程语言，JavaScript 刚好是原型模式的典型表明，正如 JAVA 是基于类模式的典范，请谨记这一语言自己在设计模式上的区别。web

不少语言因为自身的实现而限制了在其中可能应用到业务中的设计模式。但对于 JavaScript 这样的语言来讲，选择是开放性的，由于咱们常常在应用业务上听到你们讨论类继承或原型继承这样的实现方案，这即是它很是灵活的一个表现。但对于类模式和原型模式，有一些本质上的概念区别和使用混淆是不少人没有注意到的，下面对这两种设计模式作一个详细的讨论。编程

做为一种设计模式的类："Class" Design Pattern

基于类的应用或业务架构实现能够称为类设计模式，咱们在业务开发中不可避免地会使用到继承的概念即是出自于类的范畴。类不专属于 JavaScript 语言范畴，JavaScript 中实质上也没有实现真正的基于类设计模式的接口。JavaScript 中一切关于“类”的说法实际上都是一种有名无实的冒充和混淆。设计模式

咱们一般觉得在 JavaScript 中“类”是必选的，使用它来实现业务架构不只天经地义并且是惟一的——这是对 JavaScript 的最大误解。JavaScript 虽然是面向对象的编程语言，但以类做为对象模型来实现业务需求的方式只能说是一种设计模式：面向对象毫不等同于类。浏览器

类是一份产品制造说明书，指导生产机器生产符合其定义参数、具备相应功能的产品。它的用途在于规定而不在于实际使用，使用的是经过类制造出来的产品，在 JavaScript 中即对象。咱们基于复用、继承等工业化生产需求而使用类这套设计模式：规定 -> 制造 -> 使用。但咱们千万不能忘记，在工业化时代出现以前，经过手工的方式同样能够制造产品，若是你须要批量生产模样同样的东西才须要这份产品制造说明说。就手段来讲要澄清的一个误区是，类并非实现功能复用、广义上的继承等业务目标的惟一模式。性能优化

类：What's Class

类，是面向对象编程中一种通用对象模型，它是基于一种对现实中事物进行分类的抽象，天生带有类别层级的观念，如生物是一级类、动物是一个具备全部生物特性而派生出本身独有特性的二级类，依照这样的逻辑还能够继续推及到其下更多细别的子类，这是一种将全部对象进行树状类别组织关联的思惟方式：

经过这张图能够得出一个显而易见却容易被忽视的事实：永远没有一只具体的哺乳动物（好比说一只狮子）等同于哺乳动物这个类别，就像你不等于人类同样。类是一个并不具备实体的概念，是人为的发明，为了将具备相似特性的事物分门别类以适应人脑简化处理信息的方式，尽管天然并非出于这样的目的而生成各类事物的。

JavaScript 中类的概念也是人为的设计，为的是更靠近自己以类模式设计而成的语言，尽管它自己是以原型模式设计而成的。所以咱们有了 new 一个对象这种操做，为的是更符合采用类这一设计模式来实践面向对象编程。因此在此处埋下了第一个使人迷惑的种子：JavaScript 原生基于原型关联起来的对象与基于类建立的与类关联起来的对象两种概念的混淆。对于发现了这一对令人迷惑的概念的开发者来讲，便有了第一个疑问：

为何基于原型模式设计而成的 JavaScript 不继续在业务场景中使用原型设计模式，而是转而求向类设计模式？

以前有过说明，实践面向对象编程的方式有三种的，而且没有任何一种是天衣无缝的。因此请把类模式是最好的这种想法抛到九霄云外吧。暂且将这个问题移到潜意识中去，继续了解一下类范畴的的其余相关概念。

实例：What's Instance

实例的概念基于类之上。正如天然界中单一的个体便是它所属类别中的一个实例，面向对象语言中的一个对象就是它所属类中的一个实例。语言经过类的规定，生成了具备内存实体的对象。在这样的语言中，实例和对象的指代物是一致的，咱们一般在类设计模式中采用实例来描述一个内存实体，而在编程实践中使用对象来描述一个内存实体，实际上是在不一样层面上的语言转换。理解这种词语的转换，对于咱们在阅读各类技术书籍时了解做者所选择的表述视角是有帮助的。

建立实例操做的结果是将类的属性和方法分别复制到不一样的实例对象中，它们持有各自独立的版本，这也意味着每个由同一个类建立出的实例都是各自独立互不影响的个体。

而在 JavaScript 中，事情就变得没那么简单了。无论在它的设计者设计出模拟类模式的原生 API 以前仍是以后（固然官方一直有关于类的语法糖的支持），JavaScript 的世界实际上都是由且只由对象组成。当你建立了一个构造器函数或使用 ES6 的类定义语法时，其实质根本没有真的定义了类，它是由对象假装而成的。

在这一事实的基础上，就能发现既然“类”也是对象，那么咱们本觉得应用类模式创建的类与实例之间的纯粹关系就被基于对象的模拟打破了。使用上面那个大天然的归类例子再来解释下这是什么意思：当哺乳动物这一类别是一只狮子时，它既是具体又是抽象的，做为一个类这只狮子囊括了全部的哺乳动物，它是凌驾于其余具体生物之上的；做为一个具体生物它又是被包含进它自己的...这彷佛变成了一个逻辑问题。

人类在采用类这一律念时就已经将这个概念进行了抽象，它不指代任何具体的个体，即使它是一份具备实体的蓝图，也是与遵循它创造出来的物品不相同的东西。而在 JavaScript 里所发生的正是与之相矛盾的，它对于类模式的模拟实现实际上是对类模式的颠覆。

继承：What's Inheritance

继承是类范畴里的重要概念，也是咱们之因此要使用类的重要理由。继承的目的是为了实现属性或功能复用，顺便减小编写代码的机械操做。类模式的继承操做使子类拥有已经在父类里定义的属性或方法，继承而来的属性或方法是子类全部的独立版本，子类能够在此基础上继续修改已继承的属性或方法，而且扩展属于本身的属性或方法。

继承便是基于现实中类别的多级抽象。前面图示中所列出的树状结构就是对继承很好的说明。在天然过程当中，咱们从祖先那里继承而来的基因是属于复制而来的独立版本，现实中固然不存在继承而来的如出一辙的基因，但即使是如出一辙的基因序列，也是各自独立的版本，你身体中的基因不再是祖先身体中的那个基因了。

尤为强调独立这个词，是由于类模式如实地实现了对天然界这一复制过程的模拟，而在 JavaScript 这一基于原型模式设计的语言中，咱们又一次被它的表面类模式糊弄了。

在真正的类模式中，无论是父类仍是子类都是独立封装好的一份规格，若是一个子类没有继承到父类的某一属性或方法它自身也没有进行扩展时，它的实例是不可能使用这个属性或方法的。很明显 JavaScript 中的继承“完美解决了这个问题”，即使一个“类”本身没有继承也没有扩展某个属性或方法，它创造出的实例还能够从祖先那里借用。

结合实例一节所述，因而第二个问题呼之欲出：除了写法类似以外，JavaScript 中几乎全部与类相关的概念和行为都同惯常的类模式不那么相符，这真的能够被称为是类模式的实现么？

基于以上两个问题对本身进行了灵魂拷问，终于决定要来仔细瞧瞧 JavaScript 中一直被当作类的影子的那个亲骨肉——原型。

做为一种机制的原型："Prototype" Mechanism

在词汇语义上，原型的概念就与类所区别：原型是一个最初的对象。类的逻辑在于将已存在事物划分层次，达到归纳事物或分类的目的；原型的逻辑中没有抽象的层级，它是根据已存在事物寻找能表明它最初的最本源的那一个，层层溯源，途径的都是具象的。恐怕原型的概念对于熟稔哲学的人来讲比类更为亲切。它在编程上的思想是：新的物体藉由复制原型产生。

JavaScript 的原型机制就遵循了必定程度原型哲学的思路。而原型机制是 JavaScript 所特有的。原型机制的实现是，对象有一个内部属性指向另外一个对象，将两者联结起来的属性的变量名就是咱们熟悉的 __proto__，它暴露了内部实现的原型，被指向的对象被称为前者的原型，一般用 obj.__proto__ 来指代 obj 这个对象的原型。除此以外别忘记，这只是那个真实的原型对象的别称。例如 origin 是另外一个对象，如下这条语句就创建了这两个对象的原型关联关系：

let obj = {}
let origin = {}
obj.__proto__ = origin

你可使用 origin 引用它指向的那个对象，其实质是一个内存地址，也可使用 obj.__proto__ 来引用一样的内存地址。做为一个单独个体的对象和一个做为别的对象的原型的对象是合而为一的。（实际开发中不要直接使用 __proto__ ，此处只是为了简便。应该用 Object.getPrototypeOf() 方法获取原型对象）

原型机制用一句话归纳就是：将单个对象创建起原型关联关系的过程。

原型：What's Prototype

原型的语义概念上面已经介绍了，如今专门讲讲 JavaScript 中的原型。在 JavaScript 中，一切都是对象，那么这个世界总要有一个本源性的对象，就像上图中的原核生物同样，从它一辈子二而生成万物。的确，这样的一个被称为最初的原型的对象是存在的，它就是 Object.prototype，缘由是它再也没法向上追溯到任何对象了：

Object.prototype.__proto__ === null

这里咱们要知道 null 表明的是“没有”的意思。所以 JavaScript 的世界是从 Object.prototype 开始的。使用过 JavaScript 的开发者一定对这个对象印象深入，但可能不少人历来没有从这个视角看待它。

从它衍生出的一个重要的对象是一个函数 Object，它被称为构造函数，尽管由 Object 构造函数建立出来的对象的原型都是指向 Object.prototype 的，但它本身的原型对象却并非 Object.prototype，而是 Function.prototype， Function.prototype 的原型才指向的是 Object.prototype，从这里咱们能够隐隐窥见原型继承的精髓。

再次强调一下，Object 是一个名字叫作“对象”的函数，Object.prototype 是一个叫作“对象构造器原型”的对象，与其余的原生构造器原型对象同样，这些对象都是没有本身独立名称的对象。在学习 JavaScript 时，必须好好区分这些基础概念。

原型链：Prototype Chain

原型链是原型继承得以实现的基础，但其实在原型中使用“继承”这个词是不那么准确的。原型链是内部机制经过私有的“原型”属性实现对象之间的关联而造成的一条链式属性查找规则。它是单向度的，只能向上回溯，做为原型的对象没法查找它的继承者们的任何属性和方法。

原型链机制为 JavaScript 提供了实现强大功能的基础，但能够想象，每次查找都是要花费额外开销的，链条越长，开销越大。它具备一个奇特的特色，即使某个对象上并未定义变量它也不会致使程序报错，而是获得 undefined，这正是原型链机制自动查找属性的一个后果。在没有必要的状况下，应该避免编写形成无谓的原型链查找的代码。

咱们时常须要经过判断一个对象的属性存在与否实现一些分支判断，如今假设一条原型链是这样的，

obj5 -> obj4 -> obj3 -> obj2 -> obj1

它们都不具备一个叫作 prop 的属性，接着实现了以下简化了过程的判断场景：

let condition = action()
...
if (condition)  obj5.prop = true
...
if (obj5.prop) { ... }

没有任何问题的代码对不对？固然，在条件为true时一切都很完美，可是若是 condition 为 false 呢，最后那条判断语句就要查找5次最后才能回到判断，若是链条更长呢？

// 解决方案1：不须要中间变量时
obj5.prop = action()

// 解决方案2：须要中间变量时（可能二次改变）
obj5.prop = condition

// 固然还有更多变种...

或许有人以为不太可能出现这样的错误，但当代码复杂到必定程度、中间过程很是繁琐，工期很是紧迫时，一切都是有可能的，大问题都是由于那些小步骤中一个又一个的将就累积出来的。更况且做为一个有追求的开发者，即使浏览器为咱们的代码实现了最大程度的性能优化，不该该多一些对自个人要求么。

原型的做用：Why Prototype

既然类设计模式已经如此流行并深刻一代又一代开发者的脑海，那么为何还会有原型设计模式的立锥之地呢？毫无疑问是由于 JavaScript 的存在。做为网页开发脚本的 JavaScript 一直惟我独尊地统御着这片疆域，至少目前开来尚未哪种新的脚本语言可以取代它的位置。但试想一下假若有一天一种以类模式设计而成的语言能够完全取代它，原型机制将要消亡的那天大概就要来临了，没有哪种语言可以像 JavaScript 这样可以完全地实践原型机制了。

除了上面这个从语言层面来讲的使用原型模式的前提，在 JavaScript 编程中使用原型模式而不是类模式实现业务功能也有一个让人较为信服的缘由。众所周知使用类和原型的目的都是为了实现继承，或者从更本质上来讲是功能复用。

而在 JavaScript 中选择原型模式的理由就在《You Don't Know JS》这本书的章节中。做者叙述地那么明了，也不须要作额外的解析了。在此我只引用两张图做为最直观的证据：

使用类模式实现继承的逻辑图

使用原型模式实现继承的逻辑图

不少最为有效的问题处理方式一般都是最简洁的方式，那些须要经过制造一个问题而去解决另外一个问题的方法只会让人头脑晕眩，一般若是咱们不能三言两语就点出问题的核心，只能反思本身可能对问题理解得不够透彻。若是能用一个很是简单有效的方法实现一样的结果，我实在是找不出什么缘由非要去采用一个更加复杂的方法。

如上铺垫了一大堆概念，到底能从中得出什么结论？——你为何想在 JavaScript 的业务开发中使用类模式而不是原型模式？

原型模式做为 JavaScript 原生的设计模式却没有获得开发者足够的理解，这与官方挖空心思强行模拟类模式的引导不无关系。

一位国外开发者 Eric Elliott 做了一个尖锐的比喻：

Using class inheritance in JavaScript is like driving your new Tesla Model S to the dealer and trading it in for a rusted out 1973 Ford Pinto.

翻译：在 JavaScript 中使用类继承就像把你崭新的特斯拉Model S开到交易商那换了一辆生锈的1973年的福特平托。

这种比喻何以见得恐怕经过上面那两张图的比较已经有了一个大体的理解，即使是不打算放弃类模式的开发方式，深刻理解这种争议的原因更助于提升咱们的开发能力。咱们须要时不时停下来多问问几个为何。

模式之争：The War of Pattern

一直以来在 JavaScript 中使用类继承仍是原型继承彷佛不是什么值得争论的事情。但目前愈来愈多的国外开发者开始意识到原型模式在 JavaScript 中的天然性与逻辑简洁性。类模式与原型模式开始升级为不一样阵营实现功能复用的争论点。

原型与类：Prototype vs. Class

若是我说在 JavaScript 中使用类模式实现继承是不符合目前人类大脑思惟模式的复杂度的，我相信深刻理解其中原因的大多数人是会承认的，证据仍是上面那张图，有多少人可以清晰地把上面的逻辑复演出来呢？恐怕大多数人都会在来来每每的直线曲线中迷失了方向，毕竟这样的方式要求你不只要对类、子类和实例的关系把握精准，还要时刻铭记着它们暗中的原型关联关系，对于初学者来讲这种双重性关系必定是会在将来学习的道路上横梗多年的坎。因此才须要在此尤其强调类与原型的种种区别。

但若是只是将注意力集中在对象之间的原型关联关系上，事情就简单多了。要清楚的是只要 JavaScript 语言自己的实现不改变，对象的原型关联关系是咱们没法摆脱的。

不过原型与类的争论已经属于“旧时代”的争论，在随后开发者们对原型模式更加深刻的理解基础上，造成了更深入的认识和结论，“现代争论”再也不是原型与类的冲突，而是原型更新、更本质的行为委托。

原型与委托：Prototype vs. Delegation

前面有提到过在原型里说“继承”是不许确的，缘由是名副其实的类继承的行为本质上是复制，而 JavaScript 里不管是用何种方式实现“继承”，它的本质行为都不是复制。

这里要澄清一个可能的误会，JavaScript 固然是支持复制的，然而成熟的开发者都知道复制与引用原型上的方法但是彻底不同的内存消耗，也正是因为 JavaScript 的原型机制才得以经过不增长副本的方式实现“继承”，因此就此排除了这种使用复制实现“继承”的方式。

那么在 JavaScript 里“继承”的本质又是什么呢？许多开发者共同倡导了一种新的概念——委托。这种机制能够这样简单地理解：所谓的“继承”实际上是对象委托其原型们代劳办事，继承者借助原型上的方法实现功能。这个新的说法确实是比较生动地描述了原型继承机制的本质的。

之后或许开发者们会达成共识，把使用原型模式实现继承的方式称为原型委托，如此更符合它的实际状况。但究竟想使用哪一种模式进行开发最终仍是在于我的的选择，官方对类模式的不懈支持固然没法让众多开发者当即摒弃类语法糖，要从类转换到纯粹的原型上，是须要耗费思路转换和习惯改变的成本的，但愿对这个核心知识点的剖析可以使学习者们更好地理解 JavaScript 的本质语言特性，启发来者们更多的深刻思考。