JavaScript笔记：原型

[[Prototype]]

JavaScript 中的对象有一个特殊的 [[Prototype]] 内置属性，其实就是对于其他对象的引用。几乎所有的对象在创建时 [[Prototype]] 属性都会被赋予一个非空的值。

注意:很快我们就可以看到，对象的 [[Prototype]] 链接可以为空，虽然很少见。

var myObject = { 
    a:2
};
myObject.a; // 2

[[Prototype]] 引用有什么用呢？当你试图引用对象的属性时会触发[[Get]] 操作，比如 myObject.a。对于默认的 [[Get]] 操作来说，第一步是检查对象本身是否有这个属性，如果有的话就使用它。

但是如果 a 不在 myObject 中，就需要使用对象的 [[Prototype]] 链了。

对于默认的 [[Get]] 操作来说，如果无法在对象本身找到需要的属性，就会继续访问对象的 [[Prototype]] 链。

var anotherObject = { 
    a:2
};
// 创建一个关联到 anotherObject 的对象
var myObject = Object.create( anotherObject ); 
myObject.a; // 2

稍后我们会介绍 Object.create(..) 的原理，现在只需要知道它会创建一个对象并把这个对象的 [[Prototype]] 关联到指定的对象。

现在 myObject 对象的 [[Prototype]] 关联到了 anotherObject。显然 myObject.a 并不存在，但是尽管如此，属性访问仍然成功地(在 anotherObject 中)找到了值 2。

但是，如果 anotherObject 中也找不到 a 并且 [[Prototype]] 链不为空的话，就会继续查找下去。

这个过程会持续到找到匹配的属性名或者查找完整条 [[Prototype]] 链。如果是后者的话， [[Get]] 操作的返回值是 undefined。

使用 for..in 遍历对象时原理和查找 [[Prototype]] 链类似，任何可以通过原型链访问到 (并且是 enumerable)的属性都会被枚举。使用 in 操作符来检查属性在对象中是否存在时，同样会查找对象的整条原型链(无论属性是否可枚举)。

Object.prototype

但是到哪里是 [[Prototype]] 的“尽头”呢?

所有普通的 [[Prototype]] 链最终都会指向内置的 Object.prototype。由于所有的“普通”(内置，不是特定主机的扩展)对象都“源于”(或者说把 [[Prototype]] 链的顶端设置为)这个 Object.prototype 对象，所以它包含 JavaScript 中许多通用的功能。

有些功能你应该已经很熟悉了，比如说 .toString() 和 .valueOf()，还有.hasOwnProperty(..)。稍后我们还会介绍 .isPrototypeOf(..)，这个你可能不太熟悉。

属性设置和屏蔽

给一个对象设置属性并不仅仅是添加一个新属性或者修改已有的属性值。 现在我们完整地讲解一下这个过程。

myObject.foo = "bar";

如果 myObject 对象中包含名为 foo 的普通数据访问属性，这条赋值语句只会修改已有的属性值。

如果 foo 不是直接存在于 myObject 中，[[Prototype]] 链就会被遍历，类似 [[Get]] 操作。如果原型链上找不到 foo，foo 就会被直接添加到 myObject 上。

然而，如果 foo 存在于原型链上层，赋值语句 myObject.foo = “bar” 的行为就会有些不同(而且可能很出人意料)。稍后我们会进行介绍。

如果属性名 foo 既出现在 myObject 中也出现在 myObject 的 [[Prototype]] 链上层，那么就会发生屏蔽。myObject 中包含的 foo 属性会屏蔽原型链上层的所有 foo 属性，因为 myObject.foo 总是会选择原型链中最底层的 foo 属性。

下面我们分析一下如果 foo 不直接存在于 myObject 中而是存在于原型链上层时myObject.foo = “bar”会出现的三种情况。

1、如果在[[Prototype]]链上层存在名为foo的普通数据访问属性并且没有被标记为只读(writable:false)，那就会直接在 myObject 中添加一个名为 foo 的新属性，它是屏蔽属性。
2、如果在[[Prototype]]链上层存在foo，但是它被标记为只读(writable:false)，那么无法修改已有属性或者在 myObject 上创建屏蔽属性。如果运行在严格模式下，代码会抛出一个错误。否则，这条赋值语句会被忽略。总之，不会发生屏蔽。
3. 如果在[[Prototype]]链上层存在foo并且它是一个setter，那就一定会调用这个 setter。foo 不会被添加到(或者说屏蔽于)myObject，也不会重新定义 foo 这个 setter。

大多数开发者都认为如果向 [[Prototype]] 链上层已经存在的属性([[Put]])赋值，就一定会触发屏蔽，但是如你所见，三种情况中只有一种(第一种)是这样的。

如果你希望在第二种和第三种情况下也屏蔽 foo，那就不能使用 = 操作符来赋值，而是使用Object.defineProperty(..)来向 myObject 添加 foo。

第二种情况可能是最令人意外的，只读属性会阻止 [[Prototype]] 链下层隐式创建(屏蔽)同名属性。

有些情况下会隐式产生屏蔽，一定要当心：

var anotherObject = { a:2
};
var myObject = Object.create( anotherObject );
anotherObject.a; // 2
myObject.a; // 2

anotherObject.hasOwnProperty( "a" ); // true
myObject.hasOwnProperty( "a" ); // false
myObject.a++; // 隐式屏蔽! 
anotherObject.a; // 2
myObject.a; // 3
myObject.hasOwnProperty( "a" ); // true

尽管 myObject.a++ 看起来应该(通过委托)查找并增加 anotherObject.a 属性，但是别忘 了 ++ 操作相当于 myObject.a = myObject.a + 1。因此 ++ 操作首先会通过 [[Prototype]] 查找属性 a 并从 anotherObject.a 获取当前属性值 2，然后给这个值加 1，接着用 [[Put]] 将值 3 赋给 myObject 中新建的屏蔽属性 a，天呐!

修改委托属性时一定要小心。如果想让 anotherObject.a 的值增加，唯一的办法是 anotherObject.a++。

“类”

JavaScript 和面向类的语言不同，它并没有类来作为对象的抽象模式或者说蓝图。JavaScript 中只有对象。

“类”函数

多年以来，JavaScript 中有一种奇怪的行为一直在被无耻地滥用，那就是模仿类。我们会仔细分析这种方法。

这种奇怪的“类似类”的行为利用了函数的一种特殊特性：所有的函数默认都会拥有一个名为 prototype 的公有并且不可枚举的属性，它会指向另一个对象。

function Foo() { // ...
}
Foo.prototype; // { }

这个对象通常被称为 Foo 的原型。这个对象是在调用 new Foo()时创建的，最后会被关联到这个“Foo.prototype”对象上。

function Foo() { // ...
}
var a = new Foo();
Object.getPrototypeOf( a ) === Foo.prototype; // true

调用 new Foo() 时会创建 a，其中的一步就是给 a 一个内部的 [[Prototype]] 链接，关联到 Foo.prototype 指向的那个对象。

在面向类的语言中，类可以被复制(或者说实例化)多次，就像用模具制作东西一样。之所以会这样是因为实例化(或者继承)一个类就意味着“把类的行为复制到物理对象中”，对于每一个新实例来说都会重复这个过程。

但是在 JavaScript 中，并没有类似的复制机制。你不能创建一个类的多个实例，只能创建多个对象，它们 [[Prototype]] 关联的是同一个对象。但是在默认情况下并不会进行复制，因此这些对象之间并不会完全失去联系，它们是互相关联的。

new Foo()会生成一个新对象(我们称之为a)，这个新对象的内部链接[[Prototype]]关联的是 Foo.prototype 对象。

最后我们得到了两个对象，它们之间互相关联，就是这样。我们并没有初始化一个类，实际上我们并没有从“类”中复制任何行为到一个对象中，只是让两个对象互相关联。

总之，在 JavaScript 中，我们并不会将一个对象(“类”)复制到另一个对象(“实例”)，只是将它们关联起来。

这个机制通常被称为原型继承。

“构造函数”

function Foo() { // ...
}
var a = new Foo();

到底是什么让我们认为 Foo 是一个“类”呢?

其中一个原因是我们看到了关键字 new，在面向类的语言中构造类实例时也会用到它。另一个原因是，看起来我们执行了类的构造函数方法，Foo() 的调用方式很像初始化类时类构造函数的调用方式。

除了令人迷惑的“构造函数”语义外，Foo.prototype 还有另一个绝招。

function Foo() { // ...
}
Foo.prototype.constructor === Foo; // true
var a = new Foo();
a.constructor === Foo; // true

Foo.prototype 默认有一个公有并且不可枚举的属性 .constructor，这个属性引用的是对象关联的函数(本例中是 Foo)。此外，我们可以看到通过“构造函数”调用 new Foo() 创建的对象也有一个 .constructor 属性，指向 “创建这个对象的函数”。

实际上 a 本身并没有 .constructor 属性。而且，虽然 a.constructor 确实指向 Foo 函数，但是这个属性并不是表示 a 由 Foo“构造”，稍后我们会解释。

构造函数还是调用：

上一段代码很容易让人认为 Foo 是一个构造函数，因为我们使用 new 来调用它并且看到它 “构造”了一个对象。

实际上，Foo 和你程序中的其他函数没有任何区别。函数本身并不是构造函数，然而，当你在普通的函数调用前面加上 new 关键字之后，就会把这个函数调用变成一个“构造函数调用”。实际上，new 会劫持所有普通函数并用构造对象的形式来调用它。

function NothingSpecial() { 
    console.log( "Don't mind me!" );
}
var a = new NothingSpecial();
// "Don't mind me!" 
a; // {}

NothingSpecial 只是一个普通的函数，但是使用 new 调用时，它就会构造一个对象并赋值给 a，这看起来像是 new 的一个副作用(无论如何都会构造一个对象)。这个调用是一个构造函数调用，但是 NothingSpecial 本身并不是一个构造函数。

换句话说，在 JavaScript 中对于“构造函数”最准确的解释是，所有带 new 的函数调用。
函数不是构造函数，但是当且仅当使用 new 时，函数调用会变成“构造函数调用”。

技术

JavaScript 开发者绞尽脑汁想要模仿类的行为:

function Foo(name) { 
    this.name = name;
}
Foo.prototype.myName = function() { 
    return this.name;
};
var a = new Foo( "a" );
var b = new Foo( "b" ); 
a.myName(); // "a"
b.myName(); // "b"

这段代码展示了另外两种“面向类”的技巧:

1、this.name = name 给每个对象(也就是 a 和 b，参见第 2 章中的 this 绑定)都添加了 .name 属性，有点像类实例封装的数据值。
2、Foo.prototype.myName = ... 可能个更有趣的技巧，它会给 Foo.prototype 对象添加一个属性(函数)。现在，a.myName() 可以正常工作，但是你可能会觉得很惊讶，这是什么原理呢?

在这段代码中，看起来似乎创建 a 和 b 时会把 Foo.prototype 对象复制到这两个对象中， 然而事实并不是这样。

在本章开头介绍默认 [[Get]] 算法时我们介绍过 [[Prototype]] 链，以及当属性不直接存在于对象中时如何通过它来进行查找。

因此，在创建的过程中，a 和 b 的内部 [[Prototype]] 都会关联到 Foo.prototype 上。当 a 和 b 中无法找到 myName 时，它会在 Foo.prototype 上找到。

回顾“构造函数”

之前讨论 .constructor 属性时我们说过，看起来 a.constructor === Foo 为真意味着 a 确实有一个指向 Foo 的 .constructor 属性，但是事实不是这样。

这是一个很不幸的误解。实际上，.constructor 引用同样被委托给了 Foo.prototype，而Foo.prototype.constructor 默认指向 Foo。

把 .constructor 属性指向 Foo 看作是 a 对象由 Foo“构造”非常容易理解，但这只不过是一种虚假的安全感。a.constructor 只是通过默认的 [[Prototype]] 委托指向 Foo，这和构造”毫无关系。

举例来说，Foo.prototype 的 .constructor 属性只是 Foo 函数在声明时的默认属性。如果你创建了一个新对象并替换了函数默认的 .prototype 对象引用，那么新对象并不会自动获得 .constructor 属性。

function Foo() { /* .. */ }
Foo.prototype = { /* .. */ }; // 创建一个新原型对象
var a1 = new Foo();
a1.constructor === Foo; // false! 
a1.constructor === Object; // true!

原因，a1 并没有 .constructor 属性，所以它会委托 [[Prototype]] 链上的 Foo. prototype。但是这个对象也没有 .constructor 属性(不过默认的 Foo.prototype 对象有这个属性!)，所以它会继续委托，这次会委托给委托链顶端的 Object.prototype。这个对象有 .constructor 属性，指向内置的 Object(..) 函数。

实际上，对象的 .constructor 会默认指向一个函数，这个函数可以通过对象的.prototype 引用。

“constructor”和“prototype”这两个词本身的含义可能适用也可能不适用。最好的办法是记住这一点“constructor 并不表示被构造”。

一些随意的对象属性引用，比如 a1.constructor，实际上是不被信任的，它们不一定会指向默认的函数引用。此外，很快我们就会看到，稍不留神 a1.constructor 就可能会指向你意想不到的地方。

a1.constructor 是一个非常不可靠并且不安全的引用。通常来说要尽量避免使用这些引用。

(原型)继承

function Foo(name) { 
    this.name = name;
}
Foo.prototype.myName = function() { 
    return this.name;
};
function Bar(name,label) { 
    Foo.call( this, name ); 
    this.label = label;
}
// 我们创建了一个新的 Bar.prototype 对象并关联到 Foo.prototype 
Bar.prototype = Object.create( Foo.prototype );
// 注意!现在没有 Bar.prototype.constructor 了 
// 如果你需要这个属性的话可能需要手动修复一下它
Bar.prototype.myLabel = function() { 
    return this.label;
};
var a = new Bar( "a", "obj a" );
a.myName(); // "a"
a.myLabel(); // "obj a"

这段代码的核心部分就是语句 Bar.prototype = Object.create(Foo.prototype)。调用Object.create(..) 会凭空创建一个“新”对象并把新对象内部的 [[Prototype]] 关联到你指定的对象(本例中是 Foo.prototype)。

换句话说，这条语句的意思是：“创建一个新的 Bar.prototype 对象并把它关联到 Foo. prototype”。

声明function Bar() { .. }时，和其他函数一样，Bar会有一个.prototype关联到默认的对象，但是这个对象并不是我们想要的 Foo.prototype。因此我们创建了一个新对象并把它关联到我们希望的对象上，直接把原始的关联对象抛弃掉。

注意，下面这两种方式是常见的错误做法，实际上它们都存在一些问题:

// 和你想要的机制不一样! 
Bar.prototype = Foo.prototype;
// 基本上满足你的需求，但是可能会产生一些副作用 :( 
Bar.prototype = new Foo();

Bar.prototype = Foo.prototype 并不会创建一个关联到 Bar.prototype 的新对象，它只是让 Bar.prototype 直接引用 Foo.prototype 对象。因此当你执行类似 Bar.prototype. myLabel = …的赋值语句时会直接修改Foo.prototype对象本身。显然这不是你想要的结果，否则你根本不需要 Bar 对象，直接使用 Foo 就可以了，这样代码也会更简单一些。

Bar.prototype = new Foo() 的确会创建一个关联到 Bar.prototype 的新对象。但是它使用 了 Foo(..) 的“构造函数调用”，如果函数 Foo 有一些副作用(比如写日志、修改状态、注册到其他对象、给 this 添加数据属性，等等)的话，就会影响到 Bar() 的“后代”，后果不堪设想。

因此，要创建一个合适的关联对象，我们必须使用 Object.create(..) 而不是使用具有副作用的 Foo(..)。这样做唯一的缺点就是需要创建一个新对象然后把旧对象抛弃掉，不能直接修改已有的默认对象。

检查“类”关系

对象关联

现在我们知道了，[[Prototype]] 机制就是存在于对象中的一个内部链接，它会引用其他对象。

通常来说，这个链接的作用是：如果在对象上没有找到需要的属性或者方法引用，引擎就会继续在 [[Prototype]] 关联的对象上进行查找。同理，如果在后者中也没有找到需要的引用就会继续查找它的 [[Prototype]]，以此类推。这一系列对象的链接被称为“原型链”。

创建关联

那 [[Prototype]] 机制的意义是什么呢？为什么 JavaScript 开发者费这么大的力气(模拟类)在代码中创建这些关联呢？

var foo = {
    something: function() {
        console.log( "Tell me something good..." );
    }
};
var bar = Object.create( foo ); 
bar.something(); // Tell me something good...

Object.create(..) 会创建一个新对象(bar)并把它关联到我们指定的对象(foo)，这样我们就可以充分发挥 [[Prototype]] 机制的威力并且避免不必要的麻烦(比如使用 new 的构造函数调用会生成 .prototype 和 .constructor 引用)。

我们并不需要类来创建两个对象之间的关系，只需要通过委托来关联对象就足够了。而 Object.create(..) 不包含任何“类的诡计”，所以它可以完美地创建我们想要的关联关系。

Object.create(..) 是在 ES5 中新增的函数，所以在 ES5 之前的环境中(比如旧 IE)如果要支持这个功能的话就需要使用一段简单的 polyfill 代码，它部分实现了 Object. create(..) 的功能。

if (!Object.create) { 
    Object.create = function(o) {
        function F(){} 
        F.prototype = o;  
        return new F();
    }; 
}

关联关系是备用

看起来对象之间的关联关系是处理“缺失”属性或者方法时的一种备用选项。这个说法有点道理，但这并不是 [[Prototype]] 的本质。

var anotherObject = { 
    cool: function() {
        console.log( "cool!" );
    }
};
var myObject = Object.create( anotherObject ); 
myObject.cool(); // "cool!"

由于存在 [[Prototype]] 机制，这段代码可以正常工作。但是如果你这样写只是为了让 myObject 在无法处理属性或者方法时可以使用备用的 anotherObject，那么你的软件就会变得有点“神奇”，而且很难理解和维护。

这并不是说任何情况下都不应该选择备用这种设计模式，但是这在 JavaScript 中并不是很常见。所以如果你使用的是这种模式，那或许应当退后一步并重新思考一下这种模式是否合适。

当你给开发者设计软件时，假设要调用 myObject.cool()，如果 myObject 中不存在 cool() 时这条语句也可以正常工作的话，那你的 API 设计就会变得很“神奇”，对于未来维护你软件的开发者来说这可能不太好理解。

但是你可以让你的 API 设计不那么“神奇”，同时仍然能发挥 [[Prototype]] 关联的威力：

var anotherObject = { 
    cool: function() {
        console.log( "cool!" );
    }
};
var myObject = Object.create( anotherObject );
myObject.doCool = function() { 
    this.cool(); // 内部委托!
};
myObject.doCool(); // "cool!"

这里我们调用的 myObject.doCool() 是实际存在于 myObject 中的，这可以让我们的 API 设计更加清晰(不那么“神奇”)。

从内部来说，我们的实现遵循的是委托设计模式(参见下一章)，通过 [[Prototype]] 委托到anotherObject.cool()。

换句话说，内部委托比起直接委托可以让 API 接口设计更加清晰。下一章我们会详细解释委托。