Kit作为一个UI库，我并没有打算让大家都来学习我的Kit的Core，背熟我的API，这种跟风的学习方式一点意义都没有，今天jQuery热，大家都是学jQ，明天SeaJs火了，大家都去炒SeaJs，所以我在KitJs里面，专门为jQ的用户准备了一个语法糖（Suger.js），完全模拟jQ的API，除了实现，接口都一样，也方便大家直接拿来主义的改造Kit的组件。当然，作为一个纯技术Fan来说，深入理解一门技术是如何实现的，远比拿来主义更有趣的多^_^。当然了，如果你出于KPI考虑，或者老板的老板的项目奖金，直接拿来主义抄袭Kit的组件代码，完成你的KPI，我也不介意这样的行为，只要您喝水不忘挖井人，在和同事吹水的时候，也能宣传一个KitJs，我就很感激您了。同时，Kit也是一个很年轻的库，出于不断的发展之中，有一些BUG以及浏览器兼容问题，在所难免，我一个人也精力有限，在这个前端战火纷飞的年代，欢迎更多志同道合的基友一起把他搞大，共同进步。
同时，今天发布了一个kitjs的对话框组件，demo地址为
(一)Kit目录格式
言归正传，在KitJs里，kit.js是作为核心的Core文件的存在，他包含了一些最常用的Dom以及Object，继承的操作，同级目录下按照功能的划分扩展了一批string.js，math.js等等都是为了实现特定方向功能的扩展。每一个独立的js文件都包含一个Class的构造器，以及一个全局对象的实例，
以kit.js为例，包含了$Kit类，以及$Kit类的实例$kit（以$开头是为了避免与常用的变量冲突），
其他各类，都以Link的方式，挂在$Kit，以及$kit实例实例上，如math.js，包含了$Kit.Math类，以及$kit.math实例，这样保证全局范围里只有$Kit和$kit两个污染。同时，在kit.js，我们定义了一个命名空间叫做$kit.ui，在物理目录下，以kit.js同级的Widget目录，一字排开，多个首字母大写的目录
widget目录下所有目录都是kitjs的组件目录，每个独立js文件只包含一个独立组件的class构造器（非实例），同时可以兼容commonJs的module模式(可以符合CommonJs的Modules/1.1 规范，以及AMD方式改造，具体改造方式后面会以后会详细提及)
（二）Kit组件默认代码模板，注释符合jsdoc规范
我们以对话框组件举例，每个组件都类似如下
首先是jsdoc的注释，@class申明是一个什么类，@require xxx.js，申明依赖哪些组件
（三）构造器以及初始化方法
每个类都是标准的function(config){}的方式定义个构造器，这里需要注意的是，每个kitjs组件的构造器默认预留一个config参数，作为个性化配置的输入，
同时在类的构造器，有个一个静态成员，defaultConfig对象，用来存放kitjs组件的默认配置
在使用kitjs的组件，首先是需要通过new Instance的方式new $kit.ui.Dialog.YesOrNo，初始化一个新的实例对象出来，这是仅仅是初始化了一个js的组件对象，还没有HTML，需要执行init方法，创建HTML，加入doc中，等于给灵魂浇上血肉^_^。
可能有同学会问，为什么不把init方法直接放在构造器里面，而要另外单独放出来?
1是因为在继承时候需要实例化父类，当子类继承于父类的时候，会设置子类的prototype对象为父类的new Instance新的实例对象，如果在构造器里面放了init的初始化方法，会导致父类的HTML被直接执行，生成垃圾代码，
2是因为考虑懒加载的情况，需要HTML代码在恰当的时间执行，而不是一开始初始化时立即执行
所以使用kitjs组件的默认方式是
实例化之后，执行init方法（init方法会返回当前组件对象，有return代码7）
上图可以发现，在dialog中所有API method都是挂在prototype上，通过原型扩展的方式实现继承以及传递给实例对象
观察$kit.ui.Dialog.YesOrNo组件的构造器代码，
(四)KitJs的继承
他通过$kit.inherit方法申明了与$kit.ui.Dialog对象的继承关系，这里会有同学要问，为什么要在构造器里面继承，而不是直接写在外面?
原因是：
1.kitjs是一个基于prototype维护继承关系的
2.要使用kitjs的组件，必须要实例化该组件对象，每个组件都是通过new Instance的方式，通过构造器创建的