dojo.declare("VIP",{   
    getDiscount:function(){   
        this.inherited(arguments);   
        //this.inherited("getDiscount",arguments);   
    }   
});

关于构造函数:

父类构造函数总是被自动调用的，所以看下面的例子:

dojo.declare("Customer",{   
    constructor:function(name){   
        this.name = name;   
        alert("base class");   
    },say:function(){   
        alert(this.name);   
    }   
});   

dojo.declare("VIP",{   
    constructor:function(age){   
        this.age = age;   
        alert("child class");   
    },say:function(){   
        alert("name:" + this.name);   
        alert("age:" + this.age);   
    }   
});   

var vip = new VIP("123");//1   
vip.say();//2

1将打印出两条alert语句，先是父类的构造函数，再是子类的。
2将输出”name: 123″ “age: 123″

个人认为，这个特性并不好，因为javascript这种弱类型的语言中，根本无法确定构造函数中的参数是传递给谁的，就比如上面的语句执行后，name=”123″,age=”123″，那哪个才是正确的？这个问题在使用dojo Grid的model里就很麻烦，定义一个model得这样:new dojox.grid._data.Table(null,data);我要是想扩展这个Model，更麻烦，所有子类的构造函数都被父类给搞乱了。所以推荐的做法是使用关联数组作为构造函数的参数，就像Python里的关键字参数。

constructor:function(args){   
    var args = args || {};   
    this.name = args.name;   
    this.age = args.age;   
}

多继承,mixin

说到继承，多继承的问题又来了。dojo支持多继承，准确地说，是mixin。还记得dojo.declare的第二个参数吗，就是表示父类的那个参数，这个参数可以是一个数组，数组的第一个元素作为声明的类的父类，其他的作为mixin。子类自动获得父类和mixin的所有方法，后面的mixin的同名方法覆盖前面的方法

dojo.declare("Customer",{   
    say:function(){   
        alert("Hello Customer");   
    },getDiscount:function(){   
        alert("Discount in Customer");   
    }
});

dojo.declare("MixinClass",{   
    say:function(){   
        alert("Hello mixin");   
    },foo:function(){   
        alert("foo in MixinClass");   
    }   
});   
dojo.declare("VIP",[Customer,MixinClass],{   
});   
var vip = new VIP();   
vip.getDiscount();   
vip.foo();   
vip.say();//输出"Hello MixinClass"

其他的比较有用的函数就是dojo.mixin和dojo.extend了，顾名思义，一个是作用于对象实例，一个是用于扩展class，翻文档和源码吧。

package机制

说完了dojo里的类继承机制，不得不说说package机制。
主要用到的有
dojo.require
dojo.provide
dojo.registerModulePath

dojo.require

dojo.require就是引入相应路径文件下的js文件，现在已经有很多library这样做了。现在我们假设要用
project/dojo-lib/dojo/string.js

dojo中的顶层目录就是dojo.js所在目录的上一层,即”project/dojo-lib/”，而dojo.js放在
project/dojo-lib/dojo/dojo.js
所以我们就这样:
dojo.require(”dojo.string”);
比如要引用其他目录下的:
project/dojo-lib/dojox/dtl/_base.js，则这样：dojo.require(”dojox.dtl._base”);

project/dojo-lib/dojox/grid/Grid.js dojo.require(”dojox.grid.Grid”);

说白了，就和ruby之类的require很相似。

dojo.provide

要自己编写一个package怎么办，那就利用dojo.provide。比如要写在：
project/dojo-lib/com/javaeye/fyting/Package1.js
那么在对应的Package1.js中第一行需要这样写:
dojo.provide(”com.javaeye.fyting.Package1″);

类似java里的package声明，是吧？

dojo.registerModulePath

那要是我写的js文件不想和dojo放在一起怎么办呢，那就用registerModulePath。假设要放在：
project/js/com/javaeye/fyting/Package2.js

Package2.js和上面的Package1.js一样的写法，不需要作特殊变化，就这样就行：
dojo.provide(”com.javaeye.fyting.Package2″);

在使用时，需要指名这个Package2.js所在的位置，
dojo.registerModulePath(”com”,”../../js/com”);
只需要注意这里的相对路径是相对dojo.js来的。

我们假设所有以com.javaeye开头的js都放在一起，而com.microsoft的放在另外的地方，为了防止冲突，可以这样:
dojo.registerModulePath(”com.javaeye”,”../../js/com/javaeye”);
dojo.registerModulePath(”com.microsoft”,”../../javascript/com/microsoft”);

总得来说，package机制是开发大型项目必须的，但是造成了调试困难，使用dojo.require引入js出错时，根本不知道是什么原因，所以调试时最好手动引入js，dojo的test也是这么搞的。还有js框架中的各种实现类继承的手法，也造成调试困难，dojo还随地抛出个Error，又缺少java那样的error statck，根本不知道错误根源在哪儿。所以，期待js原生地支持这些^^完整的代码文件在附件里，一个是含有dojo-1.0.2的，一个是没有dojo的