JS设计模式 — 行为委托

本文介绍: 在软件架构中你可以选择是否使用类和继承设计模式。大多数开发者理所当然地认为类是唯一（合适）的代码组织方式，但是本章中我们看到了另一种更少见但是更强大的设计模式：行为委托。行为委托认为对象之间是兄弟关系，互相委托，而不是父类和子类的关系。Jav aSc rip t 的[[Pro t o type]] 机制本质上就是行为委托机制。也就是说，我们可以选择在 Jav aSc rip t 中努力实现类机制，也可以拥抱更自然的 [[Pro t o type]] 委托机制。

回顾一下原型，发现[[Pro t o type]]机制就是指对象中的一个内部链接引用另一个对象，这个机制的本质就是对象之间的关联关系

1、面相委托的设计

Task = {
	setID: function(ID) { this.id = ID; },
	outputID: function() { console.log( this.id ); }
};
// 让 XYZ 委托 Task
XYZ = Object.create( Task );
XYZ.prepareTask = function(ID,Label) {
	this.setID( ID );
	this.label = Label;
};
XYZ.outputTaskDetails = function() {
	this.outputID();
	console.log( this.label );
};
// ABC = Object.create( Task );
// ABC ... = ...

我们把这种编码风格称为“对象关联”，在JS中[[Proto type]]机制会把对象关联到其他对象，对象关联的代码会有一些不同之处：

在上面的代码中，id 和 label 数据成员都是直接存储在 XYZ 上（而不是 Task）。通常来说，在 [[Proto type]] 委托中最好把状态保存在委托者（XYZ、ABC）而不是委托目标（Task）上。
在类设计模式中，我们故意让父类（Task）和子类（XYZ）中都有 outputTask 方法，这
样就可以利用重写（多态）的优势。在委托行为中则恰好相反：我们会尽量避免在[[Prototype]] 链的不同级别中使用相同的命名，否则就需要使用笨拙并且脆弱的语法来消除引用歧义（参见第 4 章）。
这个设计模式要求尽量少使用容易被重写的通用方法名，提倡使用更有描述性的方法名，尤其是要写清相应对象行为的类型。这样做实际上可以创建出更容易理解和维护的代码，因为方法名（不仅在定义的位置，而是贯穿整个代码）更加清晰（自文档）。
th is.setID(ID)；XYZ 中的方法首先会寻找 XYZ 自身是否有 setID(…)，但是 XYZ 中并没有这个方法名，因此会通过 [[Prototype]] 委托关联到 Task 继续寻找，这时就可以找到 setID(…) 方法。此外，由于调用位置触发了 this 的隐式绑定规则（参见第 2 章），因此虽然 setID(…) 方法在 Task 中，运行时 this 仍然会绑定到 XYZ，这正是我们想要的。在之后的代码中我们还会看到 this.outputID()，原理相同。

换句话说，我们和 XYZ 进行交互时可以使用 Task 中的通用方法，因为 XYZ 委托了 Task。