说完了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","http://www.cnblogs.com/js/com");
只需要注意这里的相对路径是相对dojo.js来的。
我们假设所有以com.javaeye开头的js都放在一起，而com.microsoft的放在另外的地方，为了防止冲突，可以这样:
dojo.registerModulePath("com.javaeye","http://www.cnblogs.com/js/com/javaeye");
dojo.registerModulePath("com.microsoft","http://www.cnblogs.com/javascript/com/microsoft");
总得来说，package机制是开发大型项目必须的，但是造成了调试困难，使用dojo.require引入js出错时，根本不知道是什么原因，所以调试时最好手动引入js，dojo的test也是这么搞的。还有js框架中的各种实现类继承的手法，也造成调试困难，dojo还随地抛出个Error，又缺少java那样的error statck，根本不知道错误根源在哪儿。所以，期待js原生地支持这些。
本文转自左正博客园博客，原文链接：http://www.cnblogs.com/soundcode/archive/2011/07/26/2117562.html，如需转载请自行联系原作者
