感谢社区中各位的大力支持,译者再次奉上一点点福利:阿里云产品券,享受所有官网优惠,并抽取幸运大奖:点击这里领取
接着我们上一章对对象的探索,我们很自然的将注意力转移到“面向对象(OO)编程”,与“类(class)”。我们先将“面向类”作为设计模式来看看,之后我们再考察“类”的机制:“实例化(instantiation)”, “继承(inheritance)”与“相对多态(relative polymorphism)”。
我们将会看到,这些概念并不是非常自然地映射到JS的对象机制上,以及许多JavaScript开发者为了克服这些挑战所做的努力(mixins等)。
注意: 这一章花了相当一部分时间(前一半!)在着重解释“面向对象编程”理论上。在后半部分讨论“Mixins(混合)”时,我们最终会将这些理论与真实且实际的JavaScript代码联系起来。但是这里首先要蹚过许多概念和假想代码,所以可别迷路了——坚持下去!
类(Class)理论
“类/继承”描述了一种特定的代码组织和结构形式——一种在我们的软件中对真实世界的建模方法。
OO或者面向类的编程强调数据和操作它的行为之间有固有的联系(当然,依数据的类型和性质不同而不同!),所以合理的设计是将数据和行为打包在一起(也称为封装)。这有时在正式的计算机科学中称为“数据结构”。
比如,表示一个单词或短语的一系列字符通常称为“string(字符串)”。这些字符就是数据。但你几乎从来不关心数据,你总是想对数据 做事情, 所以可以 向 数据实施的行为(计算它的长度,在末尾添加数据,检索,等等)都被设计成为String
类的方法。
任何给定的字符串都是这个类的一个实例,这个类是一个整齐的集合包装:字符数据和我们可以对它进行的操作功能。
类还隐含着对一个特定数据结构的一种 分类 方法。我们这么做的方法是,将一个给定的结构考虑为一个更加泛化的基础定义的具体种类。
让我们通过一个最常被引用的例子来探索这种分类处理。一辆 车 可以被描述为一“类”更泛化的东西——载具——的具体实现。
我们在软件中通过定义Vehicle
类和Car
类来模型化这种关系。
Vehicle
的定义可能会包含像动力(引擎等),载人能力等等,这些都是行为。我们在Vehicle
中定义的都是所有(或大多数)不同类型的载具(飞机,火车,机动车)都共同拥有的东西。
在我们的软件中为每一种不同类型的载具一次又一次地重定义“载人能力”这个基本性质可能没有道理。反而,我们在Vehicle
中把这个能力定义一次,之后当我们定义Car
时,我们简单地指出它从基本的Vehicle
定义中“继承”(或“扩展”)。Car
的定义就是特化了一般的Vehicle
定义。
虽然Vehicle
和Car
用方法的形式集约地定义了行为,但一个实例中的数据就像一个唯一的车牌号一样属于一辆具体的车。
这样,类,继承,和实例化就诞生了。
另一个关于类的关键概念是“多态(polymorphism)”,它描述这样的想法:一个来自于父类的泛化行为可以被子类覆盖,从而使它更加具体。实际上,相对多态让我们在覆盖行为中引用基础行为。
类理论强烈建议父类和子类对相同的行为共享同样的方法名,以便于子类(差异化地)覆盖父类。我们即将看到,在你的JavaScript代码中这么做会导致种种困难和脆弱的代码。
“类(Class)”设计模式
你可能从没把类当做一种“设计模式”考虑过,因为最常见的是关于流行的“面向对象设计模式”的讨论,比如“迭代器(Iterator)”,“观察者(Observer)”,“工厂(Factory)”,“单例(Singleton)”等等。当以这种方式表现时,几乎可以假定OO的类是我们实现所有(高级)设计模式的底层机制,好像对所有代码来说OO是一个给定的基础。
取决于你在编程方面接受过的正规教育的水平,你可能听说过“过程式编程(procedural programming)”:一种不用任何高级抽象,仅仅由过程(也就是函数)调用其他函数来构成的描述代码的方式。你可能被告知过,类是一个将过程式风格的“面条代码”转换为结构良好,组织良好代码的 恰当 的方法。
当然,如果你有“函数式编程(functional programming)”的经验,你可能知道类只是几种常见设计模式中的一种。但是对于其他人来说,这可能是第一次你问自己,类是否真的是代码的根本基础,或者它们是在代码顶层上的选择性抽象。
有些语言(比如Java)不给你选择,所以这根本没什么 选择性——一切都是类。其他语言如C/C++或PHP同时给你过程式和面向类的语法,在使用哪种风格合适或混合风格上,留给开发者更多选择。
JavaScript的“类”
在这个问题上JavaScript属于哪一边?JS拥有 一些 像类的语法元素(比如new
和instanceof
)有一阵子了,而且在最近的ES6中,还有一些追加的,比如class
关键字(见附录A)。
但这意味着JavaScript实际上 拥有 类吗?直白且简单:没有。
由于类是一种设计模式,你 可以,用相当的努力(我们将在本章剩下的部分看到),近似实现很多经典类的功能。JS在通过提供看起来像类的语法,来努力满足用类进行设计的极其广泛的渴望。
虽然我们好像有了看起来像类的语法,但是好像JavaScript机制在抵抗你使用 类设计模式,因为在底层,这些你正在上面工作的机制运行的十分不同。语法糖和(极其广泛被使用的)JS“Class”库废了很大力气来把这些真实情况对你隐藏起来,但你迟早会面对现实:你在其他语言中遇到的 类 和你在JS中模拟的“类”不同。
总而言之,类是软件设计中的一种可选模式,你可以选择在JavaScript中使用或不使用它。因为许多开发者都对面向类的软件设计情有独钟,我们将在本章剩下的部分中探索一下,为了使用JS提供的东西维护类的幻觉要付出什么代价,和我们经历的痛苦。
Class 机制
在许多面向类语言中,“标准库”都提供一个叫“栈”(压栈,弹出等)的数据结构,用一个Stack
类表示。这个类拥有一组变量来存储数据,还拥有一组可公开访问的行为(“方法”),这些行为使你的代码有能力与(隐藏的)数据互动(添加或移除数据等等)。
但是在这样的语言中,你不是直接在Stack
上操作(除非制造一个 静态的 类成员引用,但这超出了我们要讨论的范围)。Stack
类仅仅是 任何 的“栈”都会做的事情的一个抽象解释,但它本身不是一个“栈”。为了得到一个可以对之进行操作的实在的数据结构,你必须 实例化 这个Stack
类。
建筑物
传统的”类(class)”和”实例(instance)”的比拟源自于建筑物的建造。
一个建筑师会规划出一栋建筑的所有性质:多宽,多高,在哪里有多少窗户,甚至墙壁和天花板用什么材料。在这个时候,她并不关心建筑物将会被建造在 哪里,她也不关心有 多少 这栋建筑的拷贝将被建造。
同时她也不关心这栋建筑的内容——家具,墙纸,吊扇等等——她仅关心建筑物含有何种结构。
她生产的建筑学上的蓝图仅仅是建筑物的“方案”。它们不实际构成我们可以实在进入其中并坐下的建筑物。为了这个任务我们需要一个建筑工。建筑工会拿走方案并精确地依照它们 建造 这栋建筑物。在真正的意义上,他是在将方案中意图的性质 拷贝 到物理建筑物中。
一旦完成,这栋建筑就是蓝图方案的一个物理实例,一个有望是实质完美的 拷贝。然后建筑工就可以移动到隔壁将它再重做一遍,建造另一个 拷贝。
建筑物与蓝图间的关系是间接的。你可以检视蓝图来了解建筑物是如何构造的,但对于直接考察建筑物的每一部分,仅有蓝图是不够的。如果你想打开一扇门,你不得不走进建筑物自身——蓝图仅仅是为了用来 表示 门的位置而在纸上画的线条。
一个类就是一个蓝图。为了实际得到一个对象并与之互动,我们必须从类中建造(也就是实例化)某些东西。这种“构建”的最终结果是一个对象,典型地称为一个“实例”,我们可以按需要直接调用它的方法,访问它的公共数据属性。
这个对象是所有在类中被描述的特性的 拷贝。
你不太指望走进一栋建筑之后发现,一份用于规划这栋建筑物的蓝图被裱起来挂在墙上,虽然蓝图可能在办公室的公共记录的文件中。相似地,你一般不会使用对象实例来直接访问和操作类,但是这至少对于判定对象实例来自于 哪个类 是可能的。
与考虑对象实例与它源自的类的任何间接关系相比,考虑类和对象实例的直接关系更有用。一个类通过拷贝操作被实例化为对象的形式。
[图片上传失败…(image-d54d08-1515410907270)]
如你所见,箭头由左向右,从上至下,这表示着概念上和物理上发生的拷贝操作。
构造器(Constructor)
类的实例由类的一种特殊方法构建,这个方法的名称通常与类名相同,称为 “构造器(constructor)”。这个方法的明确的工作,就是初始化实例所需的所有信息(状态)。
比如,考虑下面这个类的假想代码(语法是自创的):
class CoolGuy {
specialTrick = nothing
CoolGuy( trick ) {
specialTrick = trick
}
showOff() {
output( "Here's my trick: ", specialTrick )
}
}
为了 制造 一个CoolGuy
实例,我们需要调用类的构造器:
Joe = new CoolGuy( "jumping rope" )
Joe.showOff() // Here's my trick: jumping rope
注意,CoolGuy
类有一个构造器CoolGuy()
,它实际上就是在我们说new CoolGuy(..)
时调用的。我们从这个构造器拿回一个对象(类的一个实例),我们可以调用showOff()
方法,来打印这个特定的CoolGuy
的特殊才艺。
显然,跳绳使Joe看起来很酷。
类的构造器 属于 那个类,几乎总是和类同名。同时,构造器大多数情况下总是需要用new
来调用,以便使语言的引擎知道你想要构建一个 新的 类的实例。
类继承(Class Inheritance)
在面向类的语言中,你不仅可以定义一个可以初始化它自己的类,你还可以定义另外一个类 继承 自第一个类。
这第二个类通常被称为“子类”,而第一个类被称为“父类”。这些名词明显地来自于亲子关系的比拟,虽然这种比拟有些扭曲,就像你马上要看到的。
当一个家长拥有一个和他有血缘关系的孩子时,家长的遗传性质会被拷贝到孩子身上。明显地,在大多数生物繁殖系统中,双亲都平等地贡献基因进行混合。但是为了这个比拟的目的,我们假设只有一个亲人。
一旦孩子出现,他或她就从亲人那里分离出来。这个孩子受其亲人的继承因素的严重影响,但是独一无二。如果这个孩子拥有红色的头发,这并不意味这他的亲人的头发 曾经 是红色,或者会自动 变成 红色。
以相似的方式,一旦一个子类被定义,它就分离且区别于父类。子类含有一份从父类那里得来的行为的初始拷贝,但它可以覆盖这些继承的行为,甚至是定义新行为。
重要的是,要记住我们在讨论父 类 和子 类,而不是物理上的东西。这就是这个亲子比拟让人糊涂的地方,因为我们实际上应当说父类就是亲人的DNA,而子类就是孩子的DNA。我们不得不从两套DNA制造出(也就是初始化)人,用得到的物理上存在的人来与之进行谈话。
让我们把生物学上的亲子放在一边,通过一个稍稍不同的角度来看看继承:不同种类型的载具。这是用来理解继承的最经典(也是争议不断的)的比拟。
让我们重新审视本章前面的Vehicle
和Car
的讨论。考虑下面表达继承的类的假想代码:
class Vehicle {
engines = 1
ignition() {
output( "Turning on my engine." )
}
drive() {
ignition()
output( "Steering and moving forward!" )
}
}
class Car inherits Vehicle {
wheels = 4
drive() {
inherited:drive()
output( "Rolling on all ", wheels, " wheels!" )
}
}
class SpeedBoat inherits Vehicle {
engines = 2
ignition() {
output( "Turning on my ", engines, " engines." )
}
pilot() {
inherited:drive()
output( "Speeding through the water with ease!" )
}
}
注意: 为了简洁明了,这些类的构造器被省略了。
我们定义Vehicle
类,假定它有一个引擎,有一个打开打火器的方法,和一个行驶的方法。但你永远也不会制造一个泛化的“载具”,所以在这里它只是一个概念的抽象。
然后我们定义了两种具体的载具:Car
和SpeedBoat
。它们都继承Vehicle
的泛化性质,但之后它们都对这些性质进行了合适的特化。一辆车有4个轮子,一艘快艇有两个引擎,意味着它需要在打火时需要特别注意要启动两个引擎。
多态(Polymorphism)
Car
定义了自己的drive()
方法,它覆盖了从Vehicle
继承来的同名方法。但是,Car
的drive()
方法调用了inherited:drive()
,这表示Car
可以引用它继承的,覆盖之前的原版drive()
。SpeedBoat
的pilot()
方法也引用了它继承的drive()
拷贝。
这种技术称为“多态(polymorphism)”,或“虚拟多态(virtual polymorphism)”。对我们当前的情况更具体一些,我们称之为“相对多态(relative polymorphism)”。
多态这个话题比我们可以在这里谈到的内容要宽泛的多,但我们当前的“相对”意味着一个特殊层面:任何方法都可以引用位于继承层级上更高一层的其他方法(同名或不同名)。我们说“相对”,因为我们不绝对定义我们想访问继承的哪一层(也就是类),而实质上在说“向上一层”来相对地引用。
在许多语言中,在这个例子中使用inherited:
的地方使用了super
关键字,它的基于这样的想法:一个“超类(super class)”是当前类的父亲/祖先。
多态的另一个方面是,一个方法名可以在继承链的不同层面上有多种定义,而且在解析哪个方法在被调用时,这些定义可以适当地被自动选择。
在我们上面的例子中,我们看到这种行为发生了两次:drive()
在Vehicle
和Car
中定义, 而ignition()
在Vehicle
和SpeedBoat
中定义。
注意: 另一个传统面向类语言通过super
给你的能力,是从子类的构造器中直接访问父类构造器。这很大程度上是对的,因为对真正的类来说,构造器属于这个类。然而在JS中,这是相反的——实际上认为“类”属于构造器(Foo.prototype...
类型引用)更恰当。因为在JS中,父子关系仅存在于它们各自的构造器的两个.prototype
对象间,构造器本身不直接关联,而且没有简单的方法从一个中相对引用另一个(参见附录A,看看ES6中用super
“解决”此问题的class
)。
可以从ignition()
中具体看出多态的一个有趣的含义。在pilot()
内部,一个相对多态引用指向了(继承的)Vehicle
版本的drive()
。而这个drive()
仅仅通过名称(不是相对引用)来引用ignition()
方法。
语言的引擎会使用哪一个版本的ignition()
?是Vehicle
的还是SpeedBoat
的?它会使用SpeedBoat
版本的ignition()
。 如果你 能 初始化Vehicle
类自身,并且调用它的drive()
,那么语言引擎将会使用Vehicle
的ignition()
定义。
换句话说,ignition()
方法的定义,根据你引用的实例是哪个类(继承层级)而 多态(改变)。
这看起来过于深入学术细节了。不过为了好好地与JavaScript的[[Prototype]]
机制的类似行为进行对比,理解这些细节还是很重要的。
如果类是继承而来的,对这些类本身(不是由它们创建的对象)有一个方法可以 相对地 引用它们继承的对象,这个相对引用通常称为super
。
记得刚才这幅图:
[图片上传失败…(image-c7ea0e-1515410907270)]
注意对于实例化(a1
,a2
,b1
,和b2
) 和 继承(Bar
),箭头如何表示拷贝操作。
从概念上讲,看起来子类Bar
可以使用相对多态引用(也就是super
)来访问它的父类Foo
的行为。然而在现实中,子类不过是被给与了一份它从父类继承来的行为的拷贝而已。如果子类“覆盖”一个它继承的方法,原版的方法和覆盖版的方法实际上都是存在的,所以它们都是可以访问的。
不要让多态把你搞糊涂,使你认为子类是链接到父类上的。子类得到一份它需要从父类继承的东西的拷贝。类继承意味着拷贝。
多重继承(Multiple Inheritance)
能回想起我们早先提到的亲子和DNA吗?我们说过这个比拟有些奇怪,因为生物学上大多数后代来自于双亲。如果类可以继承自其他两个类,那么这个亲子比拟会更合适一些。
有些面向类的语言允许你指定一个以上的“父类”来进行“继承”。多重继承意味着每个父类的定义都被拷贝到子类中。
表面上看来,这是对面向类的一个强大的加成能力,给我们能力去将更多功能组合在一起。然而,这无疑会产生一些复杂的问题。如果两个父类都提供了名为drive()
的方法,在子类中的drive()
引用将会解析为哪个版本?你会总是不得不手动指明哪个父类的drive()
是你想要的,从而失去一些多态继承的优雅之处吗?
还有另外一个所谓的“钻石问题”:子类“D”继承自两个父类(“B”和“C”),它们两个又继承自共通的父类“A”。如果“A”提供了方法drive()
,而“B”和“C”都覆盖(多态地)了这个方法,那么当“D”引用drive()
时,它应当使用那个版本呢(B:drive()
还是C:drive()
)?
[图片上传失败…(image-909515-1515410907270)]
事情会比我们这样窥豹一斑能看到的复杂得多。我们在这里把它们记下来,以便于我们可以将它和JavaScript机制的工作方式比较。
JavaScript更简单:它不为“多重继承”提供原生机制。许多人认为这是好事,因为省去的复杂性要比“减少”的功能多得多。但是这并不能阻挡开发者们用各种方法来模拟它,我们接下来就看看。
Mixins(混合)
当你“继承”或是“实例化”时,JavaScript的对象机制不会 自动地 执行拷贝行为。很简单,在JavaScript中没有“类”可以拿来实例化,只有对象。而且对象也不会被拷贝到另一个对象中,而是被 链接在一起(详见第五章)。
因为在其他语言中观察到的类的行为意味着拷贝,让我们来看看JS开发者如何在JavaScript中 模拟 这种 缺失 的类的拷贝行为:mixins(混合)。我们会看到两种“mixin”:明确的(explicit) 和 隐含的(implicit)。
明确的 Mixins(Explicit Mixins)
让我们再次回顾前面的Vehicle
和Car
的例子。因为JavaScript不会自动地将行为从Vehicle
拷贝到Car
,我们可以建造一个工具来手动拷贝。这样的工具经常被许多包/框架称为extend(..)
,但为了说明的目的,我们在这里叫它mixin(..)
。
// 大幅简化的`mixin(..)`示例:
function mixin( sourceObj, targetObj ) {
for (var key in sourceObj) {
// 仅拷贝非既存内容
if (!(key in targetObj)) {
targetObj[key] = sourceObj[key];
}
}
return targetObj;
}
var Vehicle = {
engines: 1,
ignition: function() {
console.log( "Turning on my engine." );
},
drive: function() {
this.ignition();
console.log( "Steering and moving forward!" );
}
};
var Car = mixin( Vehicle, {
wheels: 4,
drive: function() {
Vehicle.drive.call( this );
console.log( "Rolling on all " + this.wheels + " wheels!" );
}
} );
注意: 重要的细节:我们谈论的不再是类,因为在JavaScript中没有类。Vehicle
和Car
分别只是我们实施拷贝的源和目标对象。
Car
现在拥有了一份从Vehicle
得到的属性和函数的拷贝。技术上讲,函数实际上没有被复制,而是指向函数的 引用 被复制了。所以,Car
现在有一个称为ignition
的属性,它是一个ignition()
函数引用的拷贝;而且它还有一个称为engines
的属性,持有从Vehicle
拷贝来的值1
。
Car
已经 有了drive
属性(函数),所以这个属性引用没有被覆盖(参见上面mixin(..)
的if
语句)。
重温”多态(Polymorphism)”
我们来考察一下这个语句:Vehicle.drive.call( this )
。我将之称为“显式假想多态(explicit pseudo-polymorphism)”。回想我们前一段假想代码的这一行是我们称之为“相对多态(relative polymorphism)”的inherited:drive()
。
JavaScript没有能力实现相对多态(ES6之前,见附录A)。所以,因为Car
和Vehicle
都有一个名为drive()
的函数,为了在它们之间区别调用,我们必须使用绝对(不是相对)引用。我们明确地用名称指出Vehicle
对象,然后在它上面调用drive()
函数。
但如果我们说Vehicle.drive()
,那么这个函数调用的this
绑定将会是Vehicle
对象,而不是Car
对象(见第二章),那不是我们想要的。所以,我们使用.call( this )
(见第二章)来保证drive()
在Car
对象的环境中被执行。
注意: 如果Car.drive()
的函数名称标识符没有与Vehicle.drive()
的重叠(也就是“遮蔽”;见第五章),我们就不会有机会演示“方法多态(method polymorphism)”。因为那样的话,一个指向Vehicle.drive()
的引用会被mixin(..)
调用拷贝,而我们可以使用this.drive()
直接访问它。被选用的标识符重叠 遮蔽 就是为什么我们不得不使用更复杂的 显式假想多态(explicit pseudo-polymorphism) 的原因。
在拥有相对多态的面向类的语言中,Car
和Vehicle
间的连接被建立一次,就在类定义的顶端,这里是维护这种关系的唯一场所。
但是由于JavaScript的特殊性,显式假想多态(因为遮蔽!) 在每一个你需要这种(假想)多态引用的函数中 建立了一种脆弱的手动/显式链接。这可能会显著地增加维护成本。而且,虽然显式假想多态可以模拟“多重继承”的行为,但这只会增加复杂性和代码脆弱性。
这种方法的结果通常是更加复杂,更难读懂,而且 更难维护的代码。应当尽可能地避免使用显式假想多态,因为在大部分层面上它的代价要高于利益。
混合拷贝(Mixing Copies)
回忆上面的mixin(..)
工具:
// 大幅简化的`mixin()`示例:
function mixin( sourceObj, targetObj ) {
for (var key in sourceObj) {
// 仅拷贝不存在的属性
if (!(key in targetObj)) {
targetObj[key] = sourceObj[key];
}
}
return targetObj;
}
现在,我们考察一下mixin(..)
如何工作。它迭代sourceObj
(在我们的例子中是Vehicle
)的所有属性,如果在targetObj
(在我们的例子中是Car
)中没有名称与之匹配的属性,它就进行拷贝。因为我们是在初始对象存在的情况下进行拷贝,所以我们要小心不要将目标属性覆盖掉。
如果在指明Car
的具体内容之前,我们先进行拷贝,那么我们就可以省略对targetObj
检查,但是这样做有些笨拙且低效,所以通常不优先选用:
// 另一种mixin,对覆盖不太“安全”
function mixin( sourceObj, targetObj ) {
for (var key in sourceObj) {
targetObj[key] = sourceObj[key];
}
return targetObj;
}
var Vehicle = {
// ...
};
// 首先,创建一个空对象
// 将Vehicle的内容拷贝进去
var Car = mixin( Vehicle, { } );
// 现在拷贝Car的具体内容
mixin( {
wheels: 4,
drive: function() {
// ...
}
}, Car );
不论哪种方法,我们都显式地将Vehicle
中的非重叠内容拷贝到Car
中。“mixin”这个名称来自于解释这个任务的另一种方法:Car
混入Vehicle
的内容,就像你吧巧克力碎片混入你最喜欢的曲奇饼面团。
这个拷贝操作的结果,是Car
将会独立于Vehicle
运行。如果你在Car
上添加属性,它不会影响到Vehicle
,反之亦然。
注意: 这里有几个小细节被忽略了。仍然有一些微妙的方法使两个对象在拷贝完成后还能互相“影响”对方,比如他们共享一个共通对象(比如数组)的引用。
由于两个对象还共享它们的共通函数的引用,这意味着 即便手动将函数从一个对象拷贝(也就是混入)到另一个对象中,也不能 实际上模拟 发生在面向类的语言中的从类到实例的真正的复制。
JavaScript函数不能真正意义上地被复制(以标准,可靠的方式),所以你最终得到的是同一个共享的函数对象(函数是对象;见第三章)的 被复制的引用。举例来说,如果你在一个共享的函数对象(比如ignition()
)上添加属性来修改它,Vehicle
和Car
都会通过这个共享的引用而受影响。
在JavaScript中明确的mixin是一种不错的机制。但是它们显得言过其实。和将一个属性定义两次相比,将属性从一个对象拷贝到另一个对象并不会产生多少 实际的 好处。这对我们刚才提到的给函数对象引用增加的微妙变化来说,显得尤为正确。
如果你明确地将两个或更多对象混入你的目标对象,你可以 某种程度上模拟 “多重继承”的行为,但是在将方法或属性从多于一个源对象那里拷贝过来时,没有直接的办法可以解决名称的冲突。有些开发者/包使用“late binding(延迟绑定)”和其他诡异的替代方法来解决问题,但从根本上讲,这些“技巧” 通常 得不偿失(而且低效!)。
要小心的是,仅在明确的mixin能够实际提高代码可读性时使用它,而如果你发现它使代码变得更很难追溯,或在对象间建立了不必要或笨重的依赖性时,要避免使用这种模式。
如果正确使用mixin使你的问题变得比以前 困难,那么你可能应当停止使用mixin。实际上,如果你不得不使用复杂的包/工具来处理这些细节,这可能标志着你正走在更困难,也许没必要的道路上。在第六章中,我们将试着提取一种更简单的方法来实现我们期望的结果,同时免去这些周折。
寄生继承(Parasitic Inheritance)
明确的mixin模式的一个变种,在某种意义上是明确的而在某种意义上是隐含的,称为“寄生继承(Parasitic Inheritance)”,它主要是由Douglas Crockford推广的。
这是它如何工作:
// “传统的JS类” `Vehicle`
function Vehicle() {
this.engines = 1;
}
Vehicle.prototype.ignition = function() {
console.log( "Turning on my engine." );
};
Vehicle.prototype.drive = function() {
this.ignition();
console.log( "Steering and moving forward!" );
};
// “寄生类” `Car`
function Car() {
// 首先, `car`是一个`Vehicle`
var car = new Vehicle();
// 现在, 我们修改`car`使它特化
car.wheels = 4;
// 保存一个`Vehicle::drive()`的引用
var vehDrive = car.drive;
// 覆盖 `Vehicle::drive()`
car.drive = function() {
vehDrive.call( this );
console.log( "Rolling on all " + this.wheels + " wheels!" );
};
return car;
}
var myCar = new Car();
myCar.drive();
// Turning on my engine.
// Steering and moving forward!
// Rolling on all 4 wheels!
如你所见,我们一开始从“父类”(对象)Vehicle
制造了一个定义的拷贝,之后将我们的“子类”(对象)定义混入其中(按照需要保留父类的引用),最后将组合好的对象car
作为子类实例传递出去。
注意: 当我们调用new Car()
时,一个新对象被创建并被Car
的this
所引用(见第二章)。但是由于我们没有使用这个对象,而是返回我们自己的car
对象,所以这个初始化创建的对象就被丢弃了。所以,Car()
可以不用new
关键字调用,就可以实现和上面代码相同的功能,而且还可以节省对象的创建和回收。
隐含的 Mixin(Implicit Mixins)
隐含的mixin和前面解释的 显式假想多态 是紧密相关的。所以它们需要注意相同的事项。
考虑这段代码:
var Something = {
cool: function() {
this.greeting = "Hello World";
this.count = this.count ? this.count + 1 : 1;
}
};
Something.cool();
Something.greeting; // "Hello World"
Something.count; // 1
var Another = {
cool: function() {
// 隐式地将`Something`混入`Another`
Something.cool.call( this );
}
};
Another.cool();
Another.greeting; // "Hello World"
Another.count; // 1 (不会和`Something`共享状态)
Something.cool.call( this )
既可以在“构造器”调用中使用(最常见的情况),也可以在方法调用中使用(如这里所示),我们实质上“借用”了Something.cool()
函数并在Another
环境下,而非Something
环境下调用它(通过this
绑定,见第二章)。结果是,Something.cool()
中进行的赋值被实施到了Another
对象而非Something
对象。
那么,这就是说我们将Something
的行为“混入”了Another
。
虽然这种技术看起来有效利用了this
再绑定的功能,也就是生硬地调用Something.cool.call( this )
,但是这种调用不能被作为相对(也更灵活的)引用,所以你应当 提高警惕。一般来说,尽量避免使用这种结构 来保持代码干净而且容易维护。
复习
类是一种设计模式。许多语言提供语法来启用自然而然的面向类的软件设计。JS也有相似的语法,但是它的行为和你在其他语言中熟悉的工作原理 有很大的不同。
类意味着拷贝。
当一个传统的类被实例化时,就发生了类的行为向实例中拷贝。当类被继承时,也发生父类的行为向子类的拷贝。
多态(在继承链的不同层级上拥有同名的不同函数)也许看起来意味着一个从子类回到父类的相对引用链接,但是它仍然只是拷贝行的的结果。
JavaScript 不会自动地 (像类那样)在对象间创建拷贝。
mixin模式常用于在 某种程度上 模拟类的拷贝行为,但是这通常导致像显式假想多态那样(OtherObj.methodName.call(this, ...)
)难看而且脆弱的语法,这样的语法又常导致更难懂和更难维护的代码。
显式mixin和类 拷贝 又不完全相同,因为对象(和函数!)仅仅是共享的引用被复制,不是对象/函数自身被复制。不注意这样的微小之处通常是各种陷阱的根源。
一般来讲,在JS中模拟类通常会比解决当前 真正 的问题埋下更多的坑。