浅谈JavaScript框架设计

核心提示： 关于这个，略微思考就可以知道，浅谈JavaScript框架设计(3)，Java C++ C#都是编译型语言，include 和import都是编译期处理，它是正确的做法，其中包含着这样一个简单的事实：假如你的框架中修改了Array.prototype，在js中做到类似的事情是不太可能的，为

关于这个，略微思考就可以知道，Java C++ C#都是编译型语言，include 和import都是编译期处理，在js中做到类似的事情是不太可能的。为了实现类似的功能，我想我们可以利用服务端程序或者编写一个文本工具来实现。

YUI将所有的js文件依赖关系提取出来的做法是可行的，不过这不能算是include的实现方式了，维护依赖关系不是一件很简单的事情。

8.控件

EXT的成功告诉我们：提供优质的控件才是框架的王道。你不能指望优质的扩展会吸引更多使用者。多数人只关心如何快速完成手边的工作。当然不是所有框架都要提供这部分内容。控件好坏取决于能力和美工，不过至少要保证框架里的控件不会内存泄露。

框架设计的若干原则：

1.不要做多余的事

对这框架设计来说，我认为一个非常必要的原则就是不要做多余的事情，举个极端的的例子：

function add(a,b)
{
　　return a+b;
}

这样的代码如果出现在框架中，就是个十足的笑话。不过大多数时候，事情不是那么明显，很多框架试图用某种形式在JS中"实现"OOP，但是实际上，JS本身是OO的（ECMA262中明确指出来的，不像某些人所说是基于对象云云）只是有一些语法跟Java等语言不同。那么显然这些OOP的"实现"其实是跟上面的例子一样的道理。另一个例子是Array.prototype.clone

Array.prototype.clone=function(){
return this.slice();
}

2.慎用prototype扩展

很多框架利用修改原生对象的prototype来做语言扩展，但我认为应当小心地看待这件事，毫无疑问这将造成一定的命名污染，你无法保证框架的使用者或者与你的框架共存的其他框架不会使用同样的名字来完成其他的事情。特别需要注意的是，Object和Array这两个对象的prototype扩展格外的危险，对Object来说，如果Object被修改，那么框架的使用者将无法创建一个未被修改的干净的对象，这是一个致命的问题，尤其如果你的使用者喜欢用for in来反射一个对象的属性。Array.prototype修改的危险来自js一个不知有意还是无意的小小设计，对原生的Array来说，任何情况下for和for in的遍历结果是相同的，而因为无法控制自定义的属性是不可枚举的，任何Array.prototype的修改都会破坏这种特性。一方面，我认为不应当推荐用for in遍历数组，这其中包含着错误的语义。另一方面，框架的设计者必须尊重这些使用者，因为对于ECMA所定义的语法而言，它是正确的做法。其中包含着这样一个简单的事实：假如你的框架中修改了Array.prototype，那么一些之前能正确工作的代码变得不可正确工作。