Quiz1
Javascript真的需要类（Class）么？ 我们首先先看下其他有类（Class）的面向对象语言（如：Java）的一些特性。
父类与子类 父类（Superclass）和子类（Subclass），并不是为了解决父亲与儿子的问题，而是为了解决类的包含关系的，我们用Sub表示“子类”，用Sup表示“父类”，则有：
Sub Sup
这是有区别的，例如通常我们能够将子类当成父类来使用，但认人的时候我们并不能把儿子当成父亲。
或者可以这么说，父类和子类不是为了解决类间存在相同方法或者属性的。
举个例子 有人喜欢这样做：
我们需要一些动物的类，以便在屏幕上创建一些移动的动物，但移动的动物有些在空中飞行，有些在路上行走。
所以创建两个父类，一个是Fly，一个是Walk：
Class Fly{
Fly(){}
}
Class Walk{
Walk(){}
}
然后狮子们（还可以再建些其他的在路上行走的动物）就属于Walk类，老鹰们（也还可以再建些其他在天上飞行的动物）就属于Fly类：
Class Lion extend Walk{
}
Class Eagle extend Fly{
}
最后对Lion和Eagle类创建一些实例，调用相应的方法，屏幕上就会有一些狮子和老鹰在移动了。
但这可能并不是一个好的设计，比如明天老板突然一拍大脑，他要有一种叫天马（Pegasus）的动物，它们即会在天上飞，又会在路上走，时而要飞行，时候要行走。
在这种情况下，这个方案就全然无用了。
为什么这个设计失败了？ 继承是有条件的，子类必须能严格的向上转型（变成父类）。
在上面这个例子中：
狮子（Lion）被假设等同于行走动物（Walk），老鹰（Eagle）被假设等同于飞行动物（Fly）。
这看起来很成功，因为子类能严格向上转型，但他有隐患。
当有一种天马（Pegasus）介入到里面的时候，我们才发现狮子其实只是“会行走的动物”，老鹰其实只是“会飞行的动物”，这不意味着动物一辈子只能飞行或者行走，所以即会飞行又会行走的天马就找不到自己的归属了。
这个例子很好的证明了，子类和父类不是为了解决类间具有相同的方法的：
一些动物都会行走，需要拥有行走（Walk）这个方法，但这不应该由子类和父类实现。
组合 我们可以这样解决这个问题：
Class Lion{
walker = new Walk();
walk(){
return walker.walk();
}
}
Class Eagle{
flyer = new Fly();
fly(){
return flyer.fly();
}
}
Class Pegasus{
walker = new Walk();
flyer = new Fly();
walk(){
return walker.walk();
}
fly(){
return flyer.fly();
}
}
组合是简单的在新类内部创建原有类对象。所以组合才是为了解决类间具有相同的方法的。在这个例子里面：
Walk被当成“会行走的动物应该拥有的方法集合”，同理Fly被当成“会行走的动物应该拥有的方法集合”，所以对于天马（Pegasus），我们只需要对Walk和Fly进行组合就行了。
继承的目的
继承并非代码复用的唯一方法，但继承有他的优势：
子类可以向上转型变成父类。
这样我们就可以忽略所有的子类差异，当成相同的类来操作，例如：
我们有方法fn(A)，fn(B)，这两个方法实际是相似的，我们想复用他们。
则我们可以通过设立一个父类C，其中A是C的子类，B是C的子类，那么fn(C)就可以复用在A和B身上了。
回到Javascript 但回到Javascript，我们发现上面的例子是不成立的。
因为Javascript本身是弱类型语言，它并不会在操作前（因为他不用编译）关注自己操作的对象类型是什么。他只会执行成功，或者发生错误。
这时候，继承显得并不必要了。那么类也就同样不是必要的了。
I have been writing JavaScript for 8 years now, and I have never once found need to use an uber function. The super idea is fairly important in the classical pattern, but it appears to be unnecessary in the prototypal and functional patterns. I now see my early attempts to support the classical model in JavaScript as a mistake.
——Douglas Crockford
我写Javascript代码已经8年了，但我从来没有发现需要使用超类函数。超类的想法在古典设计模式是非常重要的，但这在以原型和函数为基调的模式中并不必要。我现在觉得，早期我试图让Javascript支持经典模式是一个错误的决定。
安全环境
当然，你可以手动去判断类型，控制参数的类型，进而提供一个较为安全的环境。
例如同样作为弱类型脚本语言的PHP，为了模拟强类型面向对象语言设置安全环境，不得不这么做：
class ShopProductWriter{
public function write( $shopProduct ){
if( ! ( $shopProduct instanceof CdProduct ) && ! ( $shopProduct instanceof BookProduct ) ){
die( "输入错误的类型" );
}
//如果类型正确就执行一些代码
}
}
——PHP Objects, Patterns, and Practtice Third Edition . Matt Zandstra
但这只是一个非常丑陋的方案而已。
经典继承语法糖实现 不过经典继承依然是许多人喜欢的方式。所以YUI、Prototype、Dojo、MooTools都提供了自己的实现方案。
其中较为常见的方案中，语法大概是这样的：
var Person = Class.extend({
init: function(isDancing){
this.dancing = isDancing;
}
});
var Dancer = Person.extend({
init: function(){
this._super( true );
}
});
var n = new Dancer();
alert(n.dancing); //true
最重要的实现是对this._super的实现，其实extend函数只是将传进来的对象重新组装了一下，变成一个原型对象，新构造函数的prototype里。
具体实现请查看参考文献1。
ECMAScript 6的经典继承语法糖 对于类库各自实现，导致经典继承语法众多，ECMA组织貌似不太满意，他们试图在ECMAScript 6中加入更加直观的经典继承语法糖：
class Animal {
constructor(name) {
this.name = name;
}
sayName() {
console.log(this.name);
}
}
class Dog extends Animal {
constructor(name) {
super(name);
}
bark() {
console.log("Woof!");
}
}
总结 实际上，Javascript中经典继承并不是必要的。
然而基于许多人喜欢经典继承模型，所以在新版的ECMAScript 6中提供了相关语法糖。
不过在中国，前端想广泛使用该语法糖应该是一个遥远的故事……
Quiz2 那Javascript特有的继承呢？
原型继承 原型继承不是解决经典继承中的集合包含关系的，实际上原型继承是解决从属关系的，用数学表达就是：
Sub.prototype ∈ Sup
子级构造函数（子类型）原型是一个父级构造函数（父类型）构建的实例对象。原型实际上是子类型实例中需要共享的东西：
function Being(){
this.living = true;
}
Being.prototype.walk = function(){
alert("I' m walking");
};
function Dancer(){
this.dancing = true;
}
Dancer.prototype = new Being();
Dancer.prototype.dance = function(){
alert("I'm dancing");
};
var one = new Dancer();
one.walk();
one.dance();
利用借用、寄生等技术可以产生很多不同的继承效果，但这些技术都只是为了解决原型继承中属性和方法一些公用与非公用的问题罢了。由于篇幅问题就不展开讨论了，有兴趣可以参考《Javascript高级程序设计》相关内容。
思考题 1.文章开头关于天马（Pegasus）的题目，如果在Javascript上，应该如何设计呢？例如我们有下列两个类型：
function Walk(){
this.walk = function(){
//walk
};
}
function Fly(){
this.fly = function(){
//fly
};
}
