JavaScript面向对象的支持(3)
2008-05-25 22:56
|
然而再接下来，我们发现MyObject2()的实例obj2的constructor仍然指向function MyObject()。
尽管这很说不通，然而现实的确如此。——这到底是为什么呢？ 事实上，仅下面的代码： -------- function MyObject2() { } obj2 = new MyObject2(); document.writeln(MyObject2.prototype.constructor === MyObject2); -------- 构造的obj2.constructor将正确的指向function MyObject2()。事实上，我们也会注意到这 种情况下，MyObject2的原型属性的constructor也正确的指向该函数。然而，由于JavaScript 要求指定prototype对象来构造原型链： -------- function MyObject2() { } MyObject2.prototype = new MyObject(); obj2 = new MyObject2(); -------- 这时，再访问obj2，将会得到新的原型(也就是MyObject2.prototype)的constructor属性。 因此，一切很明了：原型的属性影响到构造过程对对象的constructor的初始设定。 作为一种补充的解决问题的手段，JavaScript开发规范中说“need to remember to reset the constructor property'，要求用户自行设定该属性。 所以你会看到更规范的JavaScript代码要求这样书写： //--------------------------------------------------------- // 维护constructor属性的规范代码 //--------------------------------------------------------- function MyObject2() { } MyObject2.prototype = new MyObject(); MyObject2.prototype.constructor = MyObject2; obj2 = new MyObject2(); 更外一种解决问题的方法，是在function MyObject()中去重置该值。当然，这样会使 得执行效率稍低一点点： //--------------------------------------------------------- // 维护constructor属性的第二种方式 //--------------------------------------------------------- function MyObject2() { this.constructor = arguments.callee; // or, this.constructor = MyObject2; // ... } MyObject2.prototype = new MyObject(); obj2 = new MyObject2(); 5). 析构问题 ------ JavaScript中没有析构函数，但却有“对象析构”的问题。也就是说，尽管我们不 知道一个对象什么时候会被析构，也不能截获它的析构过程并处理一些事务。然而， 在一些不多见的时候，我们会遇到“要求一个对象立即析构”的问题。 问题大多数的时候出现在对ActiveX Object的处理上。因为我们可能在JavaScript 里创建了一个ActiveX Object，在做完一些处理之后，我们又需要再创建一个。而 如果原来的对象供应者(Server)不允许创建多个实例，那么我们就需要在JavaScript 中确保先前的实例是已经被释放过了。接下来，即使Server允许创建多个实例，而 在多个实例间允许共享数据(例如OS的授权，或者资源、文件的锁)，那么我们在新 实例中的操作就可能会出问题。 可能还是有人不明白我们在说什么，那么我就举一个例子：如果创建一个Excel对象， 打开文件Ａ，然后我们save它，然后关闭这个实例。然后我们再创建Excel对象并打开 同一文件。——注意这时JavaScript可能还没有来得及析构前一个对象。——这时我们 再想Save这个文件，就发现失败了。下面的代码示例这种情况： //--------------------------------------------------------- // JavaScript中的析构问题(ActiveX Object示例) //--------------------------------------------------------- <script> var strSaveLocation = 'file:///E:/1.xls' function createXLS() { var excel = new ActiveXObject("Excel.Application"); var wk = excel.Workbooks.Add(); wk.SaveAs(strSaveLocation); wk.Saved = true; excel.Quit(); } function writeXLS() { var excel = new ActiveXObject("Excel.Application"); var wk = excel.Workbooks.Open(strSaveLocation); var sheet = wk.Worksheets(1); sheet.Cells(1, 1).Value = '测试字符串'; wk.SaveAs(strSaveLocation); wk.Saved = true; excel.Quit(); } </script> <body> <button onclick="createXLS()">创建</button> <button onclick="writeXLS()">重写</button> </body> 在这个例子中，在本地文件操作时并不会出现异常。——最多只是有一些内存垃 圾而已。然而，如果strSaveLocation是一个远程的URL，这时本地将会保存一个 文件存取权限的凭证，而且同时只能一个(远程的)实例来开启该excel文档并存 储。于是如果反复点击"重写"按钮，就会出现异常。 ——注意，这是在SPS中操作共享文件时的一个实例的简化代码。因此，它并非 “学术的”无聊讨论，而且工程中的实际问题。 解决这个问题的方法很复杂。它涉及到两个问题： - 本地凭证的释放 - ActiveX Object实例的释放 下面我们先从JavaScript中对象的“失效”问题说起。简单的说： - 一个对象在其生存的上下文环境之外，即会失效。 - 一个全局的对象在没有被执用(引用)的情况下，即会失效。 例如： //--------------------------------------------------------- // JavaScript对象何时失效 //--------------------------------------------------------- function testObject() { var _obj1 = new Object(); } function testObject2() { var _obj2 = new Object(); return _obj2; } // 示例1 testObject(); // 示例2 testObject2() // 示例3 var obj3 = testObject2(); obj3 = null; // 示例4 var obj4 = testObject2(); var arr = [obj4]; obj3 = null; arr = []; 在这四个示例中： - “示例1”在函数testObject()中构造了_obj1，但是在函数退出时， 它就已经离开了函数的上下文环境，因此_obj1失效了； - “示例2”中，testObject2()中也构造了一个对象_obj2并传出，因 此对象有了“函数外”的上下文环境(和生存周期)，然而由于函数 的返回值没有被其它变量“持有”，因此_obj2也立即失效了； - “示例3”中，testObject2()构造的_obj2被外部的变量obj3持用了， 这时，直到“obj3=null”这行代码生效时，_obj2才会因为引用关系 消失而失效。 - 与示例3相同的原因，“示例4”中的_obj2会在“arr=[]”这行代码 之后才会失效。 但是，对象的“失效”并不等会“释放”。在JavaScript运行环境的内部，没 有任何方式来确切地告诉用户“对象什么时候会释放”。这依赖于JavaScript 的内存回收机制。——这种策略与.NET中的回收机制是类同的。 在前面的Excel操作示例代码中，对象的所有者，也就是"EXCEL.EXE"这个进程 只能在“ActiveX Object实例的释放”之后才会发生。而文件的锁，以及操作 系统的权限凭证是与进程相关的。因此如果对象仅是“失效”而不是“释放”， 那么其它进程处理文件和引用操作系统的权限凭据时就会出问题。 ——有些人说这是JavaScript或者COM机制的BUG。其实不是，这是ＯＳ、ＩＥ 和JavaScript之间的一种复杂关系所导致的，而非独立的问题。 Microsoft公开了解决这种问题的策略：主动调用内存回收过程。 在(微软的)JScript中提供了一个CollectGarbage()过程(通常简称GC过程)， GC过程用于清理当前IE中的“失效的对象失例”，也就是调用对象的析构过程。 在上例中调用GC过程的代码是： //--------------------------------------------------------- // 处理ActiveX Object时，GC过程的标准调用方式 //--------------------------------------------------------- function writeXLS() { //(略...) excel.Quit(); excel = null; setTimeout(CollectGarbage, 1); } 第一行代码调用excel.Quit()方法来使得excel进程中止并退出，这时由于JavaScript 环境执有excel对象实例，因此excel进程并不实际中止。 第二行代码使excel为null，以清除对象引用，从而使对象“失效”。然而由于 对象仍旧在函数上下文环境中，因此如果直接调用GC过程，对象仍然不会被清理。 第三行代码使用setTimeout()来调用CollectGarbage函数，时间间隔设为'1'，只 是使得GC过程发生在writeXLS()函数执行完之后。这样excel对象就满足了“能被 GC清理”的两个条件：没有引用和离开上下文环境。 GC过程的使用，在使用了ActiveX Object的JS环境中很有效。一些潜在的ActiveX Object包括XML、VML、OWC(Office Web Componet)、flash，甚至包括在JS中的VBArray。 从这一点来看，ajax架构由于采用了XMLHTTP，并且同时要满足“不切换页面”的 特性，因此在适当的时候主动调用GC过程，会得到更好的效率用UI体验。 事实上，即使使用GC过程，前面提到的excel问题仍然不会被完全解决。因为IE还 缓存了权限凭据。使页的权限凭据被更新的唯一方法，只能是“切换到新的页面”， 因此事实上在前面提到的那个SPS项目中，我采用的方法并不是GC，而是下面这一 段代码： //--------------------------------------------------------- // 处理ActiveX Object时采用的页面切换代码 //--------------------------------------------------------- function writeXLS() { //(略...) excel.Quit(); excel = null; // 下面代码用于解决IE call Excel的一个BUG, MSDN中提供的方法: // setTimeout(CollectGarbage, 1); // 由于不能清除(或同步)网页的受信任状态, 所以将导致SaveAs()等方法在 // 下次调用时无效. location.reload(); } 最后之最后，关于GC的一个补充说明：在IE窗体被最小化时，IE将会主动调用一次 CollectGarbage()函数。这使得IE窗口在最小化之后，内存占用会有明显改善。 八、JavaScript面向对象的支持 ~~~~~~~~~~~~~~~~~~ (续) 4. 实例和实例引用 -------- 在.NET Framework对CTS(Common Type System)约定“一切都是对象”，并分为“值类型”和“引用类型”两种。其中“值类型”的对象在转换成“引用类型”数据的过程中，需要进行一个“装箱”和“拆箱”的过程。 在JavaScript也有同样的问题。我们看到的typeof关键字，返回以下六种数据类型： "number"、"string"、"boolean"、"object"、"function" 和 "undefined"。 我们也发现JavaScript的对象系统中，有String、Number、Function、Boolean这四种对象构造器。那么，我们的问题是：如果有一个数字A，typeof(A)的结果，到底会是'number'呢，还是一个构造器指向function Number()的对象呢？ //--------------------------------------------------------- // 关于JavaScript的类型的测试代码 //--------------------------------------------------------- function getTypeInfo(V) { return (typeof V == 'object' ? 'Object, construct by '+V.constructor : 'Value, type of '+typeof V); } var A1 = 100; var A2 = new Number(100); document.writeln('A1 is ', getTypeInfo(A1), '<BR>'); document.writeln('A2 is ', getTypeInfo(A2), '<BR>'); document.writeln([A1.constructor === A2.constructor, A2.constructor === Number]); 测试代码的执行结果如下： ----------- A1 is Value, type of number A2 is Object, construct by function Number() { [native code] } true,true ----------- 我们注意到，A1和A2的构造器都指向Number。这意味着通过constructor属性来识别对象，(有时)比typeof更加有效。因为“值类型数据”A1作为一个对象来看待时，与A2有完全相同的特性。 ——除了与实例引用有关的问题。 参考JScript手册，我们对其它基础类型和构造器做相同考察，可以发现： - 基础类型中的undefined、number、boolean和string，是“值类型”变量 - 基础类型中的array、function和object，是“引用类型”变量 - 使用new()方法构造出对象，是“引用类型”变量 下面的代码说明“值类型”与“引用类型”之间的区别： //--------------------------------------------------------- // 关于JavaScript类型系统中的值/引用问题 //--------------------------------------------------------- var str1 = 'abcdefgh', str2 = 'abcdefgh'; var obj1 = new String('abcdefgh'), obj2 = new String('abcdefgh'); document.writeln([str1==str2, str1===str2], '<br>'); document.writeln([obj1==obj2, obj1===obj2]); 测试代码的执行结果如下： ----------- true, true false, false ----------- 我们看到，无论是等值运算(==)，还是全等运算(===)，对“对象”和“值”的理解都是不一样的。 更进一步的理解这种现象，我们知道： - 运算结果为值类型，或变量为值类型时，等值(或全等)比较可以得到预想结果 - (即使包含相同的数据，)不同的对象实例之间是不等值(或全等)的 - 同一个对象的不同引用之间，是等值(==)且全等(===)的 但对于String类型，有一点补充：根据JScript的描述，两个字符串比较时，只要有一个是值类型，则按值比较。这意味着在上面的例子中，代码“str1==obj1”会得到结果true。而全等(===)运算需要检测变量类型的一致性，因此“str1===obj1”的结果返回false。 JavaScript中的函数参数总是传入值参，引用类型(的实例)是作为指针值传入的。因此函数可以随意重写入口变量，而不用担心外部变量被修改。但是，需要留意传入的引用类型的变量，因为对它方法调用和属性读写可能会影响到实例本身。——但，也可以通过引用类型的参数来传出数据。 最后补充说明一下，值类型比较会逐字节检测对象实例中的数据，效率低但准确性高；而引用类型只检测实例指针和数据类型，因此效率高而准确性低。如果你需要检测两个引用类型是否真的包含相同的数据，可能你需要尝试把它转换成“字符串值”再来比较。 6. 函数的上下文环境 -------- 只要写过代码，你应该知道变量是有“全局变量”和“局部变量”之分的。绝大多数的 JavaScript程序员也知道下面这些概念： //--------------------------------------------------------- // JavaScript中的全局变量与局部变量 //--------------------------------------------------------- var v1 = '全局变量-1'; v2 = '全局变量-2'; function foo() { v3 = '全局变量-3'; var v4 = '只有在函数内部并使用var定义的，才是局部变量'; } 按照通常对语言的理解来说，不同的代码调用函数，都会拥有一套独立的局部变量。 因此下面这段代码很容易理解： //--------------------------------------------------------- // JavaScript的局部变量 //--------------------------------------------------------- function MyObject() { var o = new Object; this.getValue = function() { return o; } } var obj1 = new MyObject(); var obj2 = new MyObject(); document.writeln(obj1.getValue() == obj2.getValue()); 结果显示false，表明不同(实例的方法)调用返回的局部变量“obj1/obj2”是不相同。 变量的局部、全局特性与OOP的封装性中的“私有(private)”、“公开(public)”具有类同性。因此绝大多数资料总是以下面的方式来说明JavaScript的面向对象系统中的“封装权限级别”问题： //--------------------------------------------------------- // JavaScript中OOP封装性 //--------------------------------------------------------- function MyObject() { // 1. 私有成员和方法 var private_prop = 0; var private_method_1 = function() { // ... return 1 } function private_method_2() { // ... return 1 } // 2. 特权方法 this.privileged_method = function () { private_prop++; return private_prop + private_method_1() + private_method_2(); } // 3. 公开成员和方法 this.public_prop_1 = ''; this.public_method_1 = function () { // ... } } // 4. 公开成员和方法(2) MyObject.prototype.public_prop_1 = ''; MyObject.prototype.public_method_1 = function () { // ... } var obj1 = new MyObject(); var obj2 = new MyObject(); document.writeln(obj1.privileged_method(), '<br>'); document.writeln(obj2.privileged_method()); 在这里，“私有(private)”表明只有在(构造)函数内部可访问，而“特权(privileged)”是特指一种存取“私有域”的“公开(public)”方法。“公开(public)”表明在(构造)函数外可以调用和存取。 除了上述的封装权限之外，一些文档还介绍了其它两种相关的概念： - 原型属性：Classname.prototype.propertyName = someValue - (类)静态属性：Classname.propertyName = someValue 然而，从面向对象的角度上来讲，上面这些概念都很难自圆其说：JavaScript究竟是为何、以及如何划分出这些封装权限和概念来的呢？ ——因为我们必须注意到下面这个例子所带来的问题： //--------------------------------------------------------- // JavaScript中的局部变量 //--------------------------------------------------------- function MyFoo() { var i; MyFoo.setValue = function (v) { i = v; } MyFoo.getValue = function () { return i; } } MyFoo(); var obj1 = new Object(); var obj2 = new Object(); // 测试一 MyFoo.setValue.call(obj1, 'obj1'); document.writeln(MyFoo.getValue.call(obj1), '<BR>'); // 测试二 MyFoo.setValue.call(obj2, 'obj2'); document.writeln(MyFoo.getValue.call(obj2)); document.writeln(MyFoo.getValue.call(obj1)); document.writeln(MyFoo.getValue()); 在这个测试代码中，obj1/obj2都是Object()实例。我们使用function.call()的方式来调用setValue/getValue，使得在MyFoo()调用的过程中替换this为obj1/obj2实例。 然而我们发现“测试二”完成之后，obj2、obj1以及function MyFoo()所持有的局部变量都返回了“obj2”。——这表明三个函数使用了同一个局部变量。 由此可见，JavaScript在处理局部变量时，对“普通函数”与“构造器”是分别对待的。这种处理策略在一些JavaScript相关的资料中被解释作“面向对象中的私有域”问题。而事实上，我更愿意从源代码一级来告诉你真相：这是对象的上下文环境的问题。——只不过从表面看去，“上下文环境”的问题被转嫁到对象的封装性问题上了。 (在阅读下面的文字之前，)先做一个概念性的说明： - 在普通函数中，上下文环境被window对象所持有 - 在“构造器和对象方法”中，上下文环境被对象实例所持有 在JavaScript的实现代码中，每次创建一个对象，解释器将为对象创建一个上下文环境链，用于存放对象在进入“构造器和对象方法”时对function()内部数据的一个备份。JavaScript保证这个对象在以后再进入“构造器和对象方法”内部时，总是持有该上下文环境，和一个与之相关的this对象。由于对象可能有多个方法，且每个方法可能又存在多层嵌套函数，因此这事实上构成了一个上下文环境的树型链表结构。而在构造器和对象方法之外，JavaScript不提供任何访问(该构造器和对象方法的)上下文环境的方法。 简而言之： - 上下文环境与对象实例调用“构造器和对象方法”时相关，而与(普通)函数无关 - 上下文环境记录一个对象在“构造函数和对象方法”内部的私有数据 - 上下文环境采用链式结构，以记录多层的嵌套函数中的上下文 由于上下文环境只与构造函数及其内部的嵌套函数有关，重新阅读前面的代码： //--------------------------------------------------------- // JavaScript中的局部变量 //--------------------------------------------------------- function MyFoo() { var i; MyFoo.setValue = function (v) { i = v; } MyFoo.getValue = function () { return i; } } MyFoo(); var obj1 = new Object(); MyFoo.setValue.call(obj1, 'obj1'); 我们发现setValue()的确可以访问到位于MyFoo()函数内部的“局部变量i”，但是由于setValue()方法的执有者是MyFoo对象(记住函数也是对象)，因此MyFoo对象拥有MyFoo()函数的唯一一份“上下文环境”。 接下来MyFoo.setValue.call()调用虽然为setValue()传入了新的this对象，但实际上拥有“上下文环境”的仍旧是MyFoo对象。因此我们看到无论创建多少个obj1/obj2，最终操作的都是同一个私有变量i。 全局函数/变量的“上下文环境”持有者为window，因此下面的代码说明了“为什么全局变量能被任意的对象和函数访问”： //--------------------------------------------------------- // 全局函数的上下文 //--------------------------------------------------------- /* function Window() { */ var global_i = 0; var global_j = 1; function foo_0() { } function foo_1() { } /* } window = new Window(); */ 因此我们可以看到foo_0()与foo_1()能同时访问global_i和global_j。接下来的推论是，上下文环境决定了变量的“全局”与“私有”。而不是反过来通过变量的私有与全局来讨论上下文环境问题。 更进一步的推论是：JavaScript中的全局变量与函数，本质上是window对象的私有变量与方法。而这个上下文环境块，位于所有(window对象内部的)对象实例的上下文环境链表的顶端，因此都可能访问到。 用“上下文环境”的理论，你可以顺利地解释在本小节中，有关变量的“全局／局部”作用域的问题，以及有关对象方法的封装权限问题。事实上，在实现JavaScript的C源代码中，这个“上下文环境”被叫做“JSContext”，并作为函数／方法的第一个参数传入。——如果你有兴趣，你可以从源代码中证实本小节所述的理论。 另外，《JavaScript权威指南》这本书中第4.7节也讲述了这个问题，但被叫做“变量的作用域”。然而重要的是，这本书把问题讲反了。——作者试图用“全局、局部的作用域”，来解释产生这种现象的“上下文环境”的问题。因此这个小节显得凌乱而且难以自圆其说。 |