【第767期】你不懂JS:混合(淆)“类”的对象

前言

又到周五了,这周是不是被这一系列的文章看的有点晕,如果拿着一本书会觉得挺多的,不一定能看完,但每天跟着阅读一篇可能就不会觉得多了,你觉得呢?今天继续由前端早读课专栏作者@HetfieldJoe带来连载《你不懂JS》的分享。


正文从这开始~


你不懂JS:this与对象原型 第四章:混合(淆)“类”的对象


接着我们上一章对对象的探索,我们很自然的将注意力转移到“面向对象(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)"的比拟源自于建筑物的建造。


一个建筑师会规划出一栋建筑的所有性质:多宽,多高,在哪里有多少窗户,甚至墙壁和天花板用什么材料。在这个时候,她并不关心建筑物将会被建造在 哪里,她也不关心有 多少 这栋建筑的拷贝将被建造。


同时她也不关心这栋建筑的内容——家具,墙纸,吊扇等等——她仅关心建筑物含有何种结构。


她生产的建筑学上的蓝图仅仅是建筑物的“方案”。它们不实际构成我们可以实在进入其中并坐下的建筑物。为了这个任务我们需要一个建筑工。建筑工会拿走方案并精确地依照它们 建造 这栋建筑物。在真正的意义上,他是在将方案中意图的性质 拷贝 到物理建筑物中。


一旦完成,这栋建筑就是蓝图方案的一个物理实例,一个有望是实质完美的 拷贝。然后建筑工就可以移动到隔壁将它再重做一遍,建造另一个 拷贝。


建筑物与蓝图间的关系是间接的。你可以检视蓝图来了解建筑物是如何构造的,但对于直接考察建筑物的每一部分,仅有蓝图是不够的。如果你想打开一扇门,你不得不走进建筑物自身——蓝图仅仅是为了用来 表示 门的位置而在纸上画的线条。


一个类就是一个蓝图。为了实际得到一个对象并与之互动,我们必须从类中建造(也就是实例化)某些东西。这种“构建”的最终结果是一个对象,典型地称为一个“实例”,我们可以按需要直接调用它的方法,访问它的公共数据属性。


这个对象是所有在类中被描述的特性的 拷贝。


你不太指望走进一栋建筑之后发现,一份用于规划这栋建筑物的蓝图被裱起来挂在墙上,虽然蓝图可能在办公室的公共记录的文件中。相似地,你一般不会使用对象实例来直接访问和操作类,但是这至少对于判定对象实例来自于 哪个类 是可能的。


与考虑对象实例与它源自的类的任何间接关系相比,考虑类和对象实例的直接关系更有用。一个类通过拷贝操作被实例化为对象的形式。



如你所见,箭头由左向右,从上至下,这表示着概念上和物理上发生的拷贝操作。


构造器(Constructor)

类的实例由类的一种特殊方法构建,这个方法的名称通常与类名相同,称为 “构造器(constructor)”。这个方法的明确的工作,就是初始化实例所需的所有信息(状态)。


比如,考虑下面这个类的假想代码(语法是自创的):



为了 制造 一个CoolGuy实例,我们需要调用类的构造器:



注意,CoolGuy类有一个构造器CoolGuy(),它实际上就是在我们说new CoolGuy(..)时调用的。我们从这个构造器拿回一个对象(类的一个实例),我们可以调用showOff()方法,来打印这个特定的CoolGuy的特殊才艺。


显然,跳绳使Joe看起来很酷。


类的构造器 属于 那个类,几乎总是和类同名。同时,构造器大多数情况下总是需要用new来调用,以便使语言的引擎知道你想要构建一个 新的 类的实例。


类继承(Class Inheritance)

在面向类的语言中,你不仅可以定义一个可以初始化它自己的类,你还可以定义另外一个类 继承 自第一个类。


这第二个类通常被称为“子类”,而第一个类被称为“父类”。这些名词明显地来自于亲子关系的比拟,虽然这种比拟有些扭曲,就像你马上要看到的。


当一个家长拥有一个和他有血缘关系的孩子时,家长的遗传性质会被拷贝到孩子身上。明显地,在大多数生物繁殖系统中,双亲都平等地贡献基因进行混合。但是为了这个比拟的目的,我们假设只有一个亲人。


一旦孩子出现,他或她就从亲人那里分离出来。这个孩子受其亲人的继承因素的严重影响,但是独一无二。如果这个孩子拥有红色的头发,这并不意味这他的亲人的头发 曾经 是红色,或者会自动 变成 红色。


以相似的方式,一旦一个子类被定义,它就分离且区别于父类。子类含有一份从父类那里得来的行为的初始拷贝,但它可以覆盖这些继承的行为,甚至是定义新行为。


重要的是,要记住我们在讨论父 类 和子 类,而不是物理上的东西。这就是这个亲子比拟让人糊涂的地方,因为我们实际上应当说父类就是亲人的DNA,而子类就是孩子的DNA。我们不得不从两套DNA制造出(也就是初始化)人,用得到的物理上存在的人来与之进行谈话。


让我们把生物学上的亲子放在一边,通过一个稍稍不同的角度来看看继承:不同种类型的载具。这是用来理解继承的最经典(也是争议不断的)的比拟。


让我们重新审视本章前面的Vehicle和Car的讨论。考虑下面表达继承的类的假想代码:



注意: 为了简洁明了,这些类的构造器被省略了。


我们定义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。


记得刚才这幅图:



注意对于实例化(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())?



事情会比我们这样窥豹一斑能看到的复杂得多。我们在这里把它们记下来,以便于我们可以将它和JavaScript机制的工作方式比较。


JavaScript更简单:它不为“多重继承”提供原生机制。许多人认为这是好事,因为省去的复杂性要比“减少”的功能多得多。但是这并不能阻挡开发者们用各种方法来模拟它,我们接下来就看看。


Mixins(混合)

当你“继承”或是“实例化”时,JavaScript的对象机制不会 自动地 执行拷贝行为。很简单,在JavaScript中没有“类”可以拿来实例化,只有对象。而且对象也不会被拷贝到另一个对象中,而是被 链接在一起(详见第五章)。


因为在其他语言中观察到的类的行为意味着拷贝,让我们来看看JS开发者如何在JavaScript中 模拟 这种 缺失 的类的拷贝行为:mixins(混合)。我们会看到两种“mixin”:明确的(explicit) 和 隐含的(implicit)。


明确的 Mixins(Explicit Mixins)

让我们再次回顾前面的Vehicle和Car的例子。因为JavaScript不会自动地将行为从Vehicle拷贝到Car,我们可以建造一个工具来手动拷贝。这样的工具经常被许多包/框架称为extend(..),但为了说明的目的,我们在这里叫它mixin(..)。



注意: 重要的细节:我们谈论的不再是类,因为在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(..)工具:

【第767期】你不懂JS:混合(淆)“类”的对象


现在,我们考察一下mixin(..)如何工作。它迭代sourceObj(在我们的例子中是Vehicle)的所有属性,如果在targetObj (在我们的例子中是Car)中没有名称与之匹配的属性,它就进行拷贝。因为我们是在初始对象存在的情况下进行拷贝,所以我们要小心不要将目标属性覆盖掉。


如果在指明Car的具体内容之前,我们先进行拷贝,那么我们就可以省略对targetObj检查,但是这样做有些笨拙且低效,所以通常不优先选用:

【第767期】你不懂JS:混合(淆)“类”的对象


不论哪种方法,我们都显式地将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推广的。


这是它如何工作:

【第767期】你不懂JS:混合(淆)“类”的对象


如你所见,我们一开始从“父类”(对象)Vehicle制造了一个定义的拷贝,之后将我们的“子类”(对象)定义混入其中(按照需要保留父类的引用),最后将组合好的对象car作为子类实例传递出去。


注意: 当我们调用new Car()时,一个新对象被创建并被Car的this所引用(见第二章)。但是由于我们没有使用这个对象,而是返回我们自己的car对象,所以这个初始化创建的对象就被丢弃了。所以,Car()可以不用new关键字调用,就可以实现和上面代码相同的功能,而且还可以节省对象的创建和回收。


隐含的 Mixin(Implicit Mixins)

隐含的mixin和前面解释的 显式假想多态 是紧密相关的。所以它们需要注意相同的事项。


考虑这段代码:

【第767期】你不懂JS:混合(淆)“类”的对象


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中模拟类通常会比解决当前 真正 的问题埋下更多的坑。


上一篇:【优化求解】基于matlab粒子群算法优化调度梯级水电站【含Matlab源码 767期】


下一篇:C# WebBrowser控件 模拟登录 抓取数据