6.1 面向委托的设计
为了更好地学习如何更直观地使用[[Prototype]],我们必须认识到它代表的是一种不同
于类的设计模式。
6.1.2 委托理论
你可以想象成,执行任务“XYZ”需要两个兄弟对象(XYZ 和Task)协作完成。但是我们并不需要把这些行为放在一起,通过类的复制,我们可以把它们分别放在各自独立的对象中,需要时可以允许XYZ 对象委托给Task。
下面是推荐的代码形式,非常简单:
1 | Task = { |
在这段代码中,Task 和XYZ 并不是类( 或者函数), 它们是对象。XYZ 通过Object.create(..) 创建,它的[[Prototype]] 委托了Task 对象。
相比于面向类(或者说面向对象),我会把这种编码风格称为“对象关联”(OLOO,objects linked to other objects)。我们真正关心的只是XYZ 对象(和ABC 对象)委托了Task 对象。
在JavaScript 中,[[Prototype]] 机制会把对象关联到其他对象。无论你多么努力地说服自己,JavaScript 中就是没有类似“类”的抽象机制。这有点像逆流而上:你确实可以这么做,但是如果你选择对抗事实,那要达到目的就显然会更加困难。
对象关联风格的代码还有一些不同之处:
- 在上面的代码中,id 和label 数据成员都是直接存储在XYZ 上(而不是Task)。通常来说,在[[Prototype]] 委托中最好把状态保存在委托者(XYZ、ABC)而不是委托目标(Task)上。
- 在类设计模式中,我们故意让父类(Task)和子类(XYZ)中都有outputTask 方法,这样就可以利用重写(多态)的优势。在委托行为中则恰好相反:我们会尽量避免在[[Prototype]] 链的不同级别中使用相同的命名,否则就需要使用笨拙并且脆弱的语法来消除引用歧义。
- this.setID(ID);XYZ 中的方法首先会寻找XYZ 自身是否有setID(..),但是XYZ 中并没有这个方法名,因此会通过[[Prototype]] 委托关联到Task 继续寻找,这时就可以找到setID(..) 方法。此外,由于调用位置触发了this 的隐式绑定规则(参见第2 章),因此虽然setID(..) 方法在Task 中,运行时this 仍然会绑定到XYZ,这正是我们想要的。在之后的代码中我们还会看到this.outputID(),原理相同。
换句话说,我们和XYZ 进行交互时可以使用Task 中的通用方法,因为XYZ 委托了Task。
委托行为意味着某些对象(XYZ)在找不到属性或者方法引用时会把这个请求委托给另一个对(Task)。
互相委托(禁止)
你无法在两个或两个以上互相(双向)委托的对象之间创建循环委托。如果你把B 关联到A 然后试着把A 关联到B,就会出错。
6.1.3 比较思维模型
现在你已经明白了“类”和“委托”这两种设计模式的理论区别,接下来我们看看它们在思维模型方面的区别。
我们会通过一些示例(Foo、Bar)代码来比较一下两种设计模式(面向对象和对象关联)具体的实现方法。下面是典型的(“原型”)面向对象风格:
1 | function Foo(who) { |
子类Bar 继承了父类Foo,然后生成了b1 和b2 两个实例。b1 委托了Bar.prototype,后者委托了Foo.prototype。这种风格很常见,你应该很熟悉了。
下面我们看看如何使用对象关联风格来编写功能完全相同的代码:
1 | Foo = { |
这段代码中我们同样利用[[Prototype]] 把b1 委托给Bar 并把Bar 委托给Foo,和上一段代码一模一样。我们仍然实现了三个对象之间的关联。
但是非常重要的一点是,这段代码简洁了许多,我们只是把对象关联起来,并不需要那些既复杂又令人困惑的模仿类的行为(构造函数、原型以及new)。
问问你自己:如果对象关联风格的代码能够实现类风格代码的所有功能并且更加简洁易懂,那它是不是比类风格更好?
下面我们看看两段代码对应的思维模型。
首先,类风格代码的思维模型强调实体以及实体间的关系:
从图中可以看出这是一张十分复杂的关系网。此外,如果你跟着图中的箭头走就会发现,JavaScript 机制有很强的内部连贯性。
举例来说,JavaScript 中的函数之所以可以访问call(..)、apply(..) 和bind(..)( 参见第2 章),就是因为函数本身是对象。而函数对象同样有[[Prototype]] 属性并且关联到Function.prototype 对象,因此所有函数对象都可以通过委托调用这些默认方法。
好,下面我们来看一张简化版的图,它更“清晰”一些——只展示了必要的对象和关系:
仍然很复杂,是吧?虚线表示的是Bar.prototype 继承Foo.prototype 之后丢失的.constructor
属性引用,它们还没有被修复。即使移除这些虚线,这个思维模型在你处理对象关联时仍然非常复杂。
现在我们看看对象关联风格代码的思维模型:
通过比较可以看出,对象关联风格的代码显然更加简洁,因为这种代码只关注一件事:对象之间的关联关系。
其他的“类”技巧都是非常复杂并且令人困惑的。去掉它们之后,事情会变得简单许多(同时保留所有功能)。
6.2 类与对象
我们已经看到了“类”和“行为委托”在理论和思维模型方面的区别,现在看看在真实场景中如何应用这些方法。
6.2.1 控件“类”
你可能已经习惯了面向对象设计模式,所以很快会想到一个包含所有通用控件行为的父类(可能叫作Widget)和继承父类的特殊控件子类(比如Button),这里将使用jQuery 来操作DOM 和CSS:
1 | // 父类 |
在面向对象设计模式中我们需要先在父类中定义基础的render(..),然后在子类中重写它。子类并不会替换基础的render(..),只是添加一些按钮特有的行为。
可以看到代码中出现了丑陋的显式伪多态(参见第4 章),即通过Widget.call 和Widget.prototype.render.call 从“子类”方法中引用“父类”中的基础方法。呸!
ES6的class语法糖
后面会详细介绍ES6 的class 语法糖,不过这里可以简单介绍一下如何使用class 来实现相同的功能:
1 | class Widget { |
毫无疑问,使用ES6 的class 之后,上一段代码中许多丑陋的语法都不见了,super(..)函数棒极了。(尽管深入探究就会发现并不是那么完美!)
尽管语法上得到了改进,但实际上这里并没有真正的类,class 仍然是通过[[Prototype]]机制实现的,因此我们仍然面临第4 章至第6 章提到的思维模式不匹配问题。
6.2.2 委托控件对象
下面的例子使用对象关联风格委托来更简单地实现Widget/Button:
1 | var Widget = { |
使用对象关联风格来编写代码时不需要把Widget 和Button 当作父类和子类。相反,Widget 只是一个对象,包含一组通用的函数,任何类型的控件都可以委托,Button 同样只是一个对。(当然,它会通过委托关联到Widget !)
从设计模式的角度来说, 我们并没有像类一样在两个对象中都定义相同的方法名render(..),相反,我们定义了两个更具描述性的方法名(insert(..) 和build(..))。同理,初始化方法分别叫作init(..) 和setup(..)。
在委托设计模式中,除了建议使用不相同并且更具描述性的方法名之外,还要通过对象关联避免丑陋的显式伪多态调用(Widget.call 和Widget.prototype.render.call),代之以简单的相对委托调用this.init(..) 和this.insert(..)。
如果你仔细观察就会发现,之前的一次调用(var btn1 = new Button(..))现在变成了两次(var btn1 = Object.create(Button) 和btn1.setup(..))。乍一看这似乎是一个缺点(需要更多代码)。
但是这一点其实也是对象关联风格代码相比传统原型风格代码有优势的地方。为什么呢?使用类构造函数的话,你需要(并不是硬性要求,但是强烈建议)在同一个步骤中实现构造和初始化。然而,在许多情况下把这两步分开(就像对象关联代码一样)更灵活。
举例来说,假如你在程序启动时创建了一个实例池,然后一直等到实例被取出并使用时才执行特定的初始化过程。这个过程中两个函数调用是挨着的,但是完全可以根据需要让它们出现在不同的位置。
对象关联可以更好地支持关注分离(separation of concerns)原则,创建和初始化并不需要
合并为一个步骤。
6.3 更简洁的设计
对象关联除了能让代码看起来更简洁(并且更具扩展性)外还可以通过行为委托模式简化代码结构。我们来看最后一个例子,它展示了对象关联如何简化整体设计。
在这个场景中我们有两个控制器对象,一个用来操作网页中的登录表单,另一个用来与服务器进行验证(通信)。
我们需要一个辅助函数来创建Ajax 通信。我们使用的是jQuery(尽管其他框架也做得不错),它不仅可以处理Ajax 并且会返回一个类Promise 的结果,因此我们可以使用.then(..) 来监听响应。
在传统的类设计模式中,我们会把基础的函数定义在名为Controller 的类中,然后派生两个子类LoginController 和AuthController,它们都继承自Controller 并且重写了一些基础行为:
1 | // 父类 |
所有控制器共享的基础行为是success(..)、failure(..) 和showDialog(..)。子类LoginController 和AuthController 通过重写failure(..) 和success(..) 来扩展默认基础类行为。此外,注意AuthController 需要一个LoginController 的实例来和登录表单进行交互,因此这个实例变成了一个数据属性。
另一个需要注意的是我们在继承的基础上进行了一些合成。AuthController 需要使用LoginController,因此我们实例化后者(new LoginController())并用一个类成员属性this.login 来引用它,这样AuthController 就可以调用LoginController 的行为。
你可能想让AuthController 继承LoginController 或者相反,这样我们就通过继承链实现了真正的合成。但是这就是类继承在问题领域建模时会产生的问题,因为AuthController 和LoginController 都不具备对方的基础行为,所以这种继承关系是不恰当的。我们的解决办法是进行一些简单的合成从而让它们既不必互相继承又可以互相合作。
如果你熟悉面向类设计,你一定会觉得以上内容非常亲切和自然。
反类
但是,我们真的需要用一个Controller 父类、两个子类加上合成来对这个问题进行建模吗?能不能使用对象关联风格的行为委托来实现更简单的设计呢?当然可以!
1 | var LoginController = { |
由于AuthController 只是一个对象(LoginController 也一样),因此我们不需要实例化(比如new AuthController()),只需要一行代码就行:
AuthController.checkAuth();
借助对象关联,你可以简单地向委托链上添加一个或多个对象,而且同样不需要实例化:
1 | var controller1 = Object.create( AuthController ); |
在行为委托模式中,AuthController 和LoginController 只是对象,它们之间是兄弟关系,并不是父类和子类的关系。代码中AuthController 委托了LoginController,反向委托也完全没问题。
这种模式的重点在于只需要两个实体(LoginController 和AuthController),而之前的模式需要三个。
我们不需要Controller 基类来“共享”两个实体之间的行为,因为委托足以满足我们需要的功能。同样,前面提到过,我们也不需要实例化类,因为它们根本就不是类,它们只是对象。此外,我们也不需要合成,因为两个对象可以通过委托进行合作。
最后,我们避免了面向类设计模式中的多态。我们在不同的对象中没有使用相同的函数名success(..) 和failure(..), 这样就不需要使用丑陋的显示伪多态。相反, 在AuthController 中它们的名字是accepted(..) 和rejected(..)——可以更好地描述它们的行为。
总结:我们用一种(极其)简单的设计实现了同样的功能,这就是对象关联风格代码和行为委托设计模式的力量。
6.4 更好的语法
ES6 的class 语法可以简洁地定义类方法,这个特性让class 乍看起来更有吸引力:
1 | class Foo { |
我们终于可以抛弃定义中的关键字function 了,对所有JavaScript 开发者来说真是大快人心!
你可能注意到了,在之前推荐的对象关联语法中出现了许多function,看起来违背了对象关联的简洁性。但是实际上大可不必如此!
在ES6 中我们可以在任意对象的字面形式中使用简洁方法声明(concise methoddeclaration),所以对象关联风格的对象可以这样声明(和class 的语法糖一样):
1 | var LoginController = { |
唯一的区别是对象的字面形式仍然需要使用“,”来分隔元素,而class 语法不需要。这个区别对于整体的设计来说无关紧要。
此外,在ES6 中,你可以使用对象的字面形式(这样就可以使用简洁方法定义)来改写之前繁琐的属性赋值语法( 比如AuthController 的定义), 然后用Object.setPrototypeOf(..) 来修改它的[[Prototype]]:
1 | // 使用更好的对象字面形式语法和简洁方法 |
使用ES6 的简洁方法可以让对象关联风格更加人性化(并且仍然比典型的原型风格代码更加简洁和优秀)。你完全不需要使用类就能享受整洁的对象语法!
反词法
简洁方法有一个非常小但是非常重要的缺点。思考下面的代码:
1 | var Foo = { |
去掉语法糖之后的代码如下所示:
1 | var Foo = { |
看到区别了吗? 由于函数对象本身没有名称标识符, 所以bar() 的缩写形式(function()..)实际上会变成一个匿名函数表达式并赋值给bar 属性。相比之下,具名函数表达式(function baz()..)会额外给.baz 属性附加一个词法名称标识符baz。
然后呢?在本书第一部分“作用域和闭包”中我们分析了匿名函数表达式的三大主要缺点,下面我们会简单介绍一下这三个缺点,然后和简洁方法定义进行对比。
匿名函数没有name 标识符,这会导致:
- 调试栈更难追踪;
- 自我引用(递归、事件(解除)绑定,等等)更难;
- 代码(稍微)更难理解。
简洁方法没有第1 和第3 个缺点。
去掉语法糖的版本使用的是匿名函数表达式,通常来说并不会在追踪栈中添加name,但是简洁方法很特殊,会给对应的函数对象设置一个内部的name 属性,这样理论上可以用在追踪栈中。(但是追踪的具体实现是不同的,因此无法保证可以使用。)
很不幸,简洁方法无法避免第2 个缺点,它们不具备可以自我引用的词法标识符。思考下面的代码:
1 | var Foo = { |
在本例中使用Foo.bar(x*2) 就足够了,但是在许多情况下无法使用这种方法,比如多个对象通过代理共享函数、使用this 绑定,等等。这种情况下最好的办法就是使用函数对象的name 标识符来进行真正的自我引用。
使用简洁方法时一定要小心这一点。如果你需要自我引用的话,那最好使用传统的具名函数表达式来定义对应的函数( · baz: function baz(){..}· ),不要使用简洁方法。
6.5 内省
如果你写过许多面向类的程序(无论是使用JavaScript 还是其他语言),那你可能很熟悉自省。自省就是检查实例的类型。类实例的自省主要目的是通过创建方式来判断对象的结构和功能。
下面的代码使用instanceof(参见第5 章)来推测对象a1 的功能:
1 | function Foo() { |
因为Foo.prototype( 不是Foo !) 在a1 的[[Prototype]] 链上( 参见第5 章), 所以instanceof 操作(会令人困惑地)告诉我们a1 是Foo“类”的一个实例。知道了这点后,我们就可以认为a1 有Foo“类”描述的功能。
当然,Foo 类并不存在, 只有一个普通的函数Foo, 它引用了a1 委托的对象(Foo.prototype)。从语法角度来说,instanceof 似乎是检查a1 和Foo 的关系,但是实际上它想说的是a1 和Foo.prototype(引用的对象)是互相关联的。
instanceof 语法会产生语义困惑而且非常不直观。如果你想检查对象a1 和某个对象的关系,那必须使用另一个引用该对象的函数才行——你不能直接判断两个对象是否关联。
还记得本章之前介绍的抽象的Foo/Bar/b1 例子吗,简单来说是这样的:
1 | function Foo() { /* .. */ } |
如果要使用instanceof 和.prototype 语义来检查本例中实体的关系,那必须这样做:
1 | // 让Foo 和Bar 互相关联 |
显然这是一种非常糟糕的方法。举例来说,(使用类时)你最直观的想法可能是使用Barinstanceof Foo(因为很容易把“实例”理解成“继承”),但是在JavaScript 中这是行不通的,你必须使用Bar.prototype instanceof Foo。
还有一种常见但是可能更加脆弱的内省模式,许多开发者认为它比instanceof 更好。这种模式被称为“鸭子类型”。这个术语源自这句格言“如果看起来像鸭子,叫起来像鸭子,那就一定是鸭子。”
举例来说:
1 | if (a1.something) { |
我们并没有检查a1 和委托something() 函数的对象之间的关系,而是假设如果a1 通过了测试a1.something 的话,那a1 就一定能调用.something()(无论这个方法存在于a1 自身还是委托到其他对象)。这个假设的风险其实并不算很高。
但是“鸭子类型”通常会在测试之外做出许多关于对象功能的假设,这当然会带来许多风险(或者说脆弱的设计)。
ES6 的Promise 就是典型的“鸭子类型”。
出于各种各样的原因,我们需要判断一个对象引用是否是Promise,但是判断的方法是检查对象是否有then() 方法。换句话说,如果对象有then() 方法,ES6 的Promise 就会认为这个对象是“可持续”(thenable)的,因此会期望它具有Promise 的所有标准行为。
如果有一个不是Promise 但是具有then() 方法的对象,那你千万不要把它用在ES6 的Promise 机制中,否则会出错。
这个例子清楚地解释了“鸭子类型”的危害。你应该尽量避免使用这个方法,即使使用也要保证条件是可控的。
现在回到本章想说的对象关联风格代码,其内省更加简洁。我们先来回顾一下之前的Foo/Bar/b1 对象关联例子(只包含关键代码):
1 | var Foo = { /* .. */ }; |
使用对象关联时,所有的对象都是通过[[Prototype]] 委托互相关联,下面是内省的方法,非常简单:
1 | // 让Foo 和Bar 互相关联 |
我们没有使用instanceof,因为它会产生一些和类有关的误解。现在我们想问的问题是“你是我的原型吗?”我们并不需要使用间接的形式,比如Foo.prototype 或者繁琐的Foo.prototype.isPrototypeOf(..)。
我觉得和之前的方法比起来,这种方法显然更加简洁并且清晰。再说一次,我们认为JavaScript 中对象关联比类风格的代码更加简洁(而且功能相同)。
6.6 小结
在软件架构中你可以选择是否使用类和继承设计模式。大多数开发者理所当然地认为类是唯一(合适)的代码组织方式,但是本章中我们看到了另一种更少见但是更强大的设计模式:行为委托。
行为委托认为对象之间是兄弟关系,互相委托,而不是父类和子类的关系。JavaScript 的[[Prototype]] 机制本质上就是行为委托机制。也就是说,我们可以选择在JavaScript 中努力实现类机制(参见第4 和第5 章),也可以拥抱更自然的[[Prototype]] 委托机制。
当你只用对象来设计代码时,不仅可以让语法更加简洁,而且可以让代码结构更加清晰。
对象关联(对象之前互相关联)是一种编码风格,它倡导的是直接创建和关联对象,不把 它们抽象成类。对象关联可以用基于[[Prototype]] 的行为委托非常自然地实现。
完~