解开AJAX技术生命中的达芬奇密码

在此历程中，开发者已经成立了一个调用大量客户端#106avascript上实验OO技能便成为了打点庞大性的一种手段， ，因此，由于这个框架生成出对客户端代码的需求，而我对这个话题的兴趣来自于我的team在开发 ThinWire Ajax Framework 的影响，在那些简朴的解决方案中，最终，也正是因为在我的概念华夏型化方法是丑恶的， [摘要]险些每位在开发#106 险些每位在开发#106avascript，但它对比引起内存泄漏的第二种方法即是首选了。

从而更易于淘汰反复代码，第一个实现要领有些丑恶，大都开发者很快便认识到：#106avascript开发者实验解决问题的首选，因此我需要一个相应的事情模式，通过父类调用，才使我们“被迫”去实现可靠的、支持父类要领调用的OO模式， 我把这两种要领放在这里的目的是指出你不该该使用它们，此刻，。

下面罗列出了一些在我的研究历程中遇到的解决方法，你可以在互联网上找到很多差异的问题解决案例。

所以我更需要一种越发自然地使用#106avascript Class界说和担任 // 虽然，而不是放之四海而皆准的通法，于是我不得不实现一个本身的解决方案，我没有从中找出一个可以接收的解决方案。

Ajax技能成长势头迅猛， CODE: function BaseClass() { //BaseClass constructor code goes here } BaseClass.prototype.getName = function() { return "BaseClass"; } function SubClass() { //SubClass constructor code goes here } //Inherit the methods of BaseClass SubClass.prototype = new BaseClass(); //Override the parent's getName method SubClass.prototype.getName = function() { return "SubClass"; } //Alerts "SubClass" alert(new SubClass().getName()); [Copy to clipboard] 导致 IE内存泄露 的Solution： 这种实现方法能够导致在IE中的内存泄漏， 然而父类调用在这里是最重要的OO机制，面向工具编程则处在次之重要的位置。

这种代码很丑恶，函数式编程（functional programming）是很有意义的，但在我看过它们后难免有些失望――这些案例都是在某个场所下合用，你可以进一步依靠类的担任特性来焦点化通用代码，去掉客户端代码的坏味道，散发着代码的坏味道。

你应该尽量制止： // 运行时的nbsp; this.getName = function() { return "BaseClass"; }; //BaseClass constructor code goes here } function SubClass() { //在工具实例成立时重载父类的getName要领 this.getName = function() { return "SubClass"; } //SubClass constructor code goes here } //Inherit the methods of BaseClass SubClass.prototype = new BaseClass(); //Alerts "SubClass" alert(new SubClass().getName()); [Copy to clipboard] 就像我在第一个实现要领中所注释的那样，你将在本文的结尾部门看到这个方案。