一：构造法继承
昨天扔了一堆JavaScript类'继承'的代码，这些代码其实并不是所有的都能正常的执行。不是我不原意写出都能好好执行的继承类代码，而是这些方法本身就各自有自己的优缺点。下面我分别说它们的原理和使用时注意事项。
构造继承法的原理：
构造继承法关键代码是function ArrayList01()中的：
this.base = CollectionBase; this.base();
这里的base不是C#派生类中的base那个概念，完全就是一个任意的JavaScript变量名。调用this.base();其实就是执行的CollectionBase();，不过不是new CollectionBase();哦！没有new基类那么怎么得到CollectionBase中的方法和属性呢？这里使用了this作用域的一个hack，'欺骗'了脚本引擎。当我们从类ArrayList01的构造函数中调用this.base();时，在基类CollectionBase中的this就是ArrayList01的一个实例，于是执行CollectionBase的构造函数，就动态的把基类的成员和方法attach到ArrayList01实例中了。构造法的问题也就是从这里产生了，注意哦。
构造继承法的缺陷：
第一个问题，关键是出在上面那两段代码上，因为始终没有new基类呀。这样带来的问题就是不能把基类CollectionBase中的原型属性和方法attach到ArrayList01的实例中，啊，这样还算是什么继承啊?! 所以在上篇文章中我为了不改动CollectionBase类，而单独为其实现了一个Add()方法(只是为了统一示例代码而已)。解决这个缺陷的方法其实也很简单，就是要求基类不能使用prototype来导入属性和方法，而要把所有的属性和方法都写到构造函数中去，分别是：this.Attribute = ...; 和 this.Method = function() {...};这种形式。
第二个问题，是this.base = CollectionBase;和this.base();必须写在派生类构造函数的最开头(不是一定要是第一行和第二行，而是它们的前面不能有this.xxx这种定义为ArrayList01导入的任何属性或方法)，因为调用this.base();时会向this(ArrayList01的一个实例)中注入基类的属性和方法，如果基类中有和this中已导入的属性和方法重名的，就自动覆盖掉子类中的方法。
第三个问题，是子类也不能使用prototype来导入属性和方法，这和问题二中的重名覆盖道理一样，由于prototype导入的属性和方法在子类一new的时候就生成了，所以也存在和基类重名而被覆盖的潜在错误威胁。解决办法，和基类编写规则一样不要使用prototype，并且将子类的属性和方法定义代码放在导入继承的代码(this.base = CollectionBase;this.base();)之后。
构造继承法的示例：
<script language="JavaScript">
document.write('构造继承法:<br>');var arrayList11 = new ArrayList01();arrayList11.Add('a');arrayList11.Add('b');arrayList11.foo();var arrayList12 = new ArrayList01();arrayList12.Add('a');arrayList12.Add('b');arrayList12.Add('c');
arrayList12.foo();</script>
示例运行结果为：
构造继承法:[class ArrayList01]: 2: a,b[class ArrayList01]: 3: a,b,c
小结一下：JavaScript的构造继承法其实看起来还是比较直观的，因为子类构造函数中有对基类构造函数的调用，似乎在语法上还比较容易被接受。可是由于没有new基类，带来了不能获得prototype导入的属性和方法的缺陷。解决这个缺陷的方法虽然不难，可是由此而给基类编写限制一个凌驾于JavaScript语法规范的规则，可操作性不是很好。子类也不能利用prototype特性来导入属性和方法，会与基类之间存在潜在的重名覆盖问题。所以对于复杂的基类，不推荐这种继承方法，因为类复杂了，使用prototype可以规范类代码，使类的定义看起来比较的舒服
。
应用场景：小规模类之间的继承，基类和子类的属性方法在5-8个。还有就是以构造函数中赋值方式导入类的属性和方法，而不用prototype导入的类编写习惯的时候。
二：原型继承法
原型(prototype)是JavaScript实现面向对象编程的一个基础，但它并不是唯一的构造类的方法，我们完全可以不使用 prototype而实现类的编写(把属性和方法的附加全都写在构造函数里面就行了)。不过原型除了可以为Object的子类添加新的属性和方法外，它还可以为脚本环境中的内部对象继续添加原型属性和方法，比如我们最常用的给内部对象String添加一个Trim方法来删除字符串两端的空格，代码为：
{
return this.replace(/(^\s*)|(\s*$)/g, '');
}
这样我们就可以在任何的String实例中使用Trim方法了，用惯了这种原型系统，有的时候反而还觉得传统OOP没有它爽，kaka。言归正传，继续讲我们的原型继承法。
原型继承法的原理：
原型继承法的关键代码是其构造函数function ArrayList02()下的第一句：
ArrayList02.prototype.constructor = ArrayList02;
Ae… 把prototype都覆盖成基类的一个实例了，子类还怎么使用prototype呢？这里不要着急，反正JavaScript的对象实例都是可以动态增删属性和方法的，基类实例作为prototype不就正好等于extends了CollectionBase吗？之后再使用 XXX.prototype.xxx = function()，可以继续获得新增了属性和方法的对象。注意ArrayList02.prototype是在ArrayList02的构造函数外被初始化为基类的实例的。
再来看第二句，为什么要把ArrayList02赋值给新prototype的constructor呢？如果不做这个赋值，当我们从 ArrayList02的实例中，通过???.prototype.constructor去却其构造函数，将会获得CollectionBase。这不是我们的本意，而且这是使用instanceof关键之比较对象实例和对象也会出错。
原型继承法的缺陷：
原型继承法有两个缺陷，第一个是由于类的原型(prototype)实际上是一个Object的实例，它不能再次被实例化(它的初始化在脚本装载时已经执行完毕)。这么意思呢？我们知道在新建对象实例时，我们使用语句new ArrayList02()，这时我们可以看做JavaScript脚本引擎把prototype的一个浅拷贝作为this返回给类的实例(这里其实没有发生拷贝，只是利用浅拷贝这个概念来帮助理解)，如果类没有附加任何原型属性和原型方法，那么就等于返回了一个new Object()实例。问题就出在这里了，由于new对 prototype执行的是浅拷贝，如果prototype的原型属性里有对象类型的属性，那么就会造成共享对象实例的问题(类似于在传统OOP的类定义中使用了static修饰符来修饰了属性)。这个缺陷下面会有示例演示，避免的办法就是不要在基类中定义对象类型的属性，比如: Array、Object和Date等。
第二个缺陷和上次讲的"构造继承法"的缺陷差不多，也是关于子类定义是语句顺序的。就是说代码：ArrayList02.prototype = new CollectionBase();必须在所有prototype定义之前执行，很简单，如果在原型属性和方法都导入完成后，再执行这个语句，就定于把之前的导入全都覆盖掉了:(。解决办法就是按我给文章(1)中的那个顺序来写，郁闷吧？kaka
原型继承法的示例：
<script language="JavaScript">document.write('原形继承法:<br>'); var arrayList21 = new ArrayList02();arrayList21.Add('a');arrayList21.Add('b');arrayList21.foo();var arrayList22 = new ArrayList02();arrayList22.Add('a');arrayList22.Add('b');arrayList22.Add('c');arrayList22.foo();</script>
示例运行结果为：
原形继承法:[class ArrayList02]: 2: a,b[class ArrayList02]: 3: a,b,c,a,b
发现问题了吧
？实例arrayList22的foo()居然输出了a,b,c,a,b@_@... 这就是前面说的prototype对象浅拷贝带来的问题。不过为什么arrayList22中的集合计数器却仍然是3呢？这是因为this.m_Count是整数类型，这种类型又叫值类型(和C#里的值类型、对象类型概念一样的)。值类型不存在浅拷贝和深拷贝的问题，可以看成都是深拷贝。
小结：JavaScript的原型继承法，虽然有prototype浅拷贝那么严重的bug，不过它却是使用比较多的继承方式。因为我们很少在基类里定义属性，更别说对象类型的属性了，所以引发这个错误的可能性不是很大，只是它是个潜在的隐患:(。至于第二个缺陷，也是一个潜在bug，只要自己定义类的时候能比较清醒就不会犯错误。'重载'也比较简单，如果在ArrayList02.prototype = new CollectionBase();后有重名的属性或方法导入，自动覆盖基类中的属性或方法就像当于重载了。
应用场景：基类没有属性，至少是要没有对象类型的属性。这种继承的优点是保持了子类构造函数的完整，可以不在里面添加任何和继承有关系的代码，所有继承和重载操作都由对原型(prototype)的操作来完成。
三：实例继承法
实例继承法的原理：
实例继承法的关键代码是其构造函数function ArrayList03()中的：
var base = new CollectionBase(); // ... return base;
其实就是在子类构造时创建基类的一个实例，然后把基类实例作为返回值实返回。这时的所谓继承操作都是对Object实例(基类也就是一个Object的派生类的实例)的动态读写，为其添加属性和方法等，根本没有涉及任何与继承相关的范畴，不过最终的效果上还是让人觉的是实现了继承。
实例继承法的缺陷：
这种继承法看起来还是比较清楚的，特别是如果你已理解了JavaScript对象的动态特性。不过这种方法最大的缺陷也是来至于对类代码的书写的要求上，由于我们在子类构造函数中创建了基类实例，所以对基类的书写时没有任何的要求，只要是一个脚本引擎认为正确的类就可以了。不过子类就不能随便写了，由于子类的属性和方法通过对象的动态特性来实现，所以子类也不能使用原型属性(prototype)来实现属性和方法的导入，而必须用inline的方式写在子类的构造函数里，这个和构造法实现继承的限制很相似，不过前者是限制基类的书写不能使用prototype属性。
实例继承法的示例：
document.write('实例继承法:<br>'); var arrayList31 = new ArrayList03(); arrayList31.Add('a'); arrayList31.Add('b'); arrayList31.foo(); var arrayList32 = new ArrayList03(); arrayList32.Add('a'); arrayList32.Add('b'); arrayList32.Add('c'); arrayList32.foo();
示例运行结果：
实例继承法: [class ArrayList03]: 2: a,b [class ArrayList03]: 3: a,b,c
小结：实例继承法其实有些偷梁换柱的味道，因为这样得到的实例，针对instanceOf来说的话，完全是其基类的一个扩展。而子类的实例是被扔掉了的，因为new ArrayList03()返回的是基类实例(return base;)。这完全没有了任何继承的味道，叫做类扩展还贴切些
。优点是对基类的编写没有任何特殊要求，不过同样需要规定子类的写法，子类不能使用prototype来导入原型方法，并且在子类构造函数中创建基类实例var base = new CollectionBase();需要在构造函数开头(即任何向base添加属性和方法之前)。
应用场景：没有太经典的应用场景，不过对于基类比较复杂，而子类需要添加的属性方法很少的继承，实例法还是显得挺清晰的。特别是对于JScript对象动态扩展很熟悉的人，就更觉得明确了。
四：附加继承法
附加继承法，虽然是我自己杜撰出来的，而且还有一些前面三种继承法的影子，不过这个方法不可否认的，可以把前面说到继承的问题都cut掉
。下面我们就来仔细说说到底它是为什么这么有武功和智慧的呢？
附加继承法的原理：
附加继承法的关键代码是其构找函数ArrayList04()中的：
this.base = new CollectionBase(); for ( var key in this.base ) { if ( !this[key] ) { this[key] = this.base[key]; } }
这里其实给不给this附加一个base并不重要，也一点不会影响我们的这个继承方法。首先我们看到在构造函数的第一句话中，我们立马就new了一个基类实例出来，这就说明我们的继承对基类的书写是没有任何要求的，用前面实例继承法中的说法就是，只要脚本引擎认为正确的类就都可以。我们知道构造继承法为什么有问题呢？就是因为它始终没有创建基类的实例。而原型继承法虽然也创建了基类实例，不过它把积累实例直接赋给了子类的prototype属性，以至于搞的对子类书写有特殊的要求。
然后接下来一个for( in )循环，把基类具有的所有属性和方法都附加到子类的实例this中了，这也是我把这个继承方法叫附加法的原因。这一步和构造继承法的原理相当的类似，只是构造继承法是用了this作用域置换的一个技巧，把这个附加的过程让基类构造函数来完成了，不过同时也给构造继承法带来基类书写的特别要求，不能使用其prototype特性。当然附加法仍然是没有这个要求的。
附加继承法的Update：
Object.prototype.Extends = function(BaseClass) { if ( arguments.length >= 6 ) { throw new Error('Only can supprot at most 5 parameters.'); } var base; if ( arguments.length > 1 ) { var arg01 = arguments[1]; var arg02 = arguments[2]; var arg03 = arguments[3]; var arg04 = arguments[4]; base = new BaseClass(arg01, arg02, arg03, arg04); } else { base = new BaseClass(); } for ( var key in base ) { if ( !this[key] ) { this[key] = base[key]; if ( typeof(base[key]) != 'function' ) { delete base[key]; } } } this.base = base; // base.Inherit = this; };
这样我们就的继承就可以直接写成：
function ArrayList04() { this.Extends(CollectionBase); // ... }
同时还提供了对基类继承时，传递参数给基类的支持，比如：
function ListItem() { this.Extends(ListItemBase, text, value); // ... }
对于基类，会执行new ListItemBase(text, value);这样的操作来生成基类的实例。
附加继承法的缺陷：
从目前我的使用来看，如果不使用override技术来重写方法，然后还在新的方法中去调用基类的方法(这个技术我会以后再讲，因为它不影响也不属于我们今天讨论的继承方式的这个话题)的话。附加法基本没有缺陷，一定要说有就的话就是：使用一个for( in )循环来进行基类的导入，语法上很ugly:(
附加继承法的示例：
document.write('附加继承法:<br>'); var arrayList41 = new ArrayList04(); arrayList41.Add('a'); arrayList41.Add('b'); arrayList41.foo(); var arrayList42 = new ArrayList04(); arrayList42.Add('a'); arrayList42.Add('b'); arrayList42.Add('c'); arrayList42.foo();
示例运行结果为：
附加继承法: [class ArrayList04]: 2: a,b [class ArrayList04]: 3: a,b,c
小结：附加继承法是看起来最不像继承，但却是实际使用中最sexy(PS:这是我们boss对好代码的称呼)的解决方案。其override也非常的清晰明了，只要在this.Extends(BaseClass);语句后有同名的方法被导入子类，就会自动覆盖从基类中导入的方法，实现override的效果。
使用场景：anywhere, anytime, anybody...
这话似乎说大了
，完美的东西一定是没有的，附加继承法也是有缺陷的，只不过这个缺陷不属于继承这个范畴，而是对其它OO编程特性的模拟中出现的问题，以后再谈。再唐僧一下：光是类的继承和使用，附加继承法是没有任何问题的。
总算完成了JScript模拟面向对象编程中实现继承的各种研究。