javascript设计模式理论和示例深入分析(下)

6.2.4 组合使用构造函数模式和原型模式(解决原型模式中引用类型值不能的实例不能私有化问题)

创建自定义类型的最常见方式,就是组合使用构造函数模式与原型模式。构造函数模式用于定义实例属性,而原型模式用于定义方法和共享的属性。结果,每个实例都会有自己的一份实例属性的副本,但同时又共享着对方法的引用,最大限度地节省了内存。另外,这种混成模式还支持向构造函数传递参数;可谓是集两种模式之长。下面的代码重写了前面的例子。

function Person(name, age, job){
this.name = name;
this.age = age;
this.job = job;
this.friends = ["Shelby", "Court"];
}
Person.prototype = {
constructor : Person,
sayName : function(){
alert(this.name);
}
}
var person1 = new Person("Nicholas", 29, "Software Engineer");
var person2 = new Person("Greg", 27, "Doctor");
person1.friends.push("Van");
alert(person1.friends); //"Shelby,Count,Van"
alert(person2.friends); //"Shelby,Count"
alert(person1.friends === person2.friends); //false
alert(person1.sayName === person2.sayName); //true
 

在这个例子中,实例属性都是在构造函数中定义的,而由所有实例共享的属性 constructor 和方法 sayName() 则是在原型中定义的。而修改了 person1.friends (向其中添加一个新字符串) ,并不会影响到 person2.friends ,因为它们分别引用了不同的数组。这种构造函数与原型混成的模式,是目前在 ECMAScript中使用最广泛、认同度最高的一种创建自定义类型的方法。可以说,这是用来定义引用类型的一种默认模式。

6.2.5 动态原型模式

有其他 OO 语言经验的开发人员在看到独立的构造函数和原型时,很可能会感到非常困惑。动态原型模式正是致力于解决这个问题的一个方案,它把所有信息都封装在了构造函数中,而通过在构造函数中初始化原型(仅在必要的情况下) ,又保持了同时使用构造函数和原型的优点。换句话说,可以通过检查某个应该存在的方法是否有效,来决定是否需要初始化原型。来看一个例子。

function Person(name, age, job){
//属性
this.name = name;

this.age = age;

this.job = job;

// 方法
if (typeof this.sayName != "function"){
   Person.prototype.sayName = function(){
   alert(this.name);
   };
}

}
var friend = new Person("Nicholas", 29, "Software Engineer");
friend.sayName();
 
注意构造函数代码中加粗的部分。这里只在 sayName() 方法不存在的情况下,才会将它添加到原型中。这段代码只会在初次调用构造函数时才会执行。此后,原型已经完成初始化,不需要再做什么修改了。不过要记住,这里对原型所做的修改,能够立即在所有实例中得到反映。因此,这种方法确实可以说非常完美。其中, if 语句检查的可以是初始化之后应该存在的任何属性或方法——不必用一大堆if 语句检查每个属性和每个方法;只要检查其中一个即可。对于采用这种模式创建的对象,还可以使用 instanceof
操作符确定它的类型。使用动态原型模式时,不能使用对象字面量重写原型。前面已经解释过了,如果在已经创建了实例的情况下重写原型,那么就会切断现有实例与新原型之间的联系。

6.2.6 寄生构造函数模式
通常,在前述的几种模式都不适用的情况下,可以使用寄生(parasitic)构造函数模式。这种模式的基本思想是创建一个函数,该函数的作用仅仅是封装创建对象的代码,然后再返回新创建的对象;但从表面上看,这个函数又很像是典型的构造函数。下面是一个例子。

function Person(name, age, job){
var o = new Object();
o.name = name;
o.age = age;
o.job = job;
o.sayName = function(){
alert(this.name);
};
return o;
}
var friend = new Person("Nicholas", 29, "Software Engineer");
friend.sayName(); //"Nicholas"
 
在这个例子中, Person 函数创建了一个新对象,并以相应的属性和方法初始化该对象,然后又返回了这个对象。 除了使用 new 操作符并把使用的包装函数叫做构造函数之外, 这个模式跟工厂模式其实是一模一样的。构造函数在不返回值的情况下,默认会返回新对象实例。而通过在构造函数的末尾添加一个 return 语句,可以重写调用构造函数时返回的值。这个模式可以在特殊的情况下用来为对象创建构造函数。 假设我们想创建一个具有额外方法的特殊数组。由于不能直接修改 Array 构造函数,因此可以使用这个模式。

function SpecialArray(){
//创建数组
var values = new Array();
//添加值
values.push.apply(values, arguments);  //call 以参数表来接受被调用函数的参数
//添加方法
values.toPipedString = function(){
return this.join("|");
};
//返回数组
return values;
}
var colors = new SpecialArray("red", "blue", "green");
alert(colors.toPipedString()); //"red|blue|green"
 
在这个例子中,我们创建了一个名叫 SpecialArray 的构造函数。在这个函数内部,首先创建了一个数组,然后 push() 方法(用构造函数接收到的所有参数)初始化了数组的值。随后,又给数组实例添加了一个 toPipedString() 方法,该方法返回以竖线分割的数组值。最后,将数组以函数值的形式返回。接着,我们调用了 SpecialArray 构造函数,向其中传入了用于初始化数组的值,此后又调用了 toPipedString() 方法。关于寄生构造函数模式,有一点需要说明:首先,返回的对象与构造函数或者与构造函数的原型属
性之间没有关系;也就是说,构造函数返回的对象与在构造函数外部创建的对象没有什么不同。为此,不能依赖 instanceof 操作符来确定对象类型。 由于存在上述问题, 我们建议在可以使用其他模式的情况下,不要使用这种模式。

6.2.7 稳妥构造函数模式
道格拉斯·克罗克福德(Douglas Crockford)发明了 JavaScript 中的稳妥对象(durable objects)这个概念。所谓稳妥对象,指的是没有公共属性,而且其方法也不引用 this 的对象。稳妥对象最适合在一些安全的环境中 (这些环境中会禁止使用 this 和 new ) , 或者在防止数据被其他应用程序 (如 Mashup程序)改动时使用。稳妥构造函数遵循与寄生构造函数类似的模式,但有两点不同:一是新创建对象的实例方法不引用 this
;二是不使用 new 操作符调用构造函数
。按照稳妥构造函数的要求,可以将前面
的 Person 构造函数重写如下。

function Person(name, age, job){
//创建要返回的对象
var o = new Object();

//可以在这里定义私有变量和函数
//添加方法
o.sayName = function(){
alert(name);
};
//返回对象
return o;
}
注意, 在以这种模式创建的对象中, 除了使用 sayName() 方法之外, 没有其他办法访问 name 的值。可以像下面使用稳妥的 Person 构造函数。
var friend = Person("Nicholas", 29, "Software Engineer");
friend.sayName(); //"Nicholas"
这样,变量 friend 中保存的是一个稳妥对象,而除了调用 sayName() 方法外,没有别的方式可以访问其数据成员。即使有其他代码会给这个对象添加方法或数据成员,但也不可能有别的办法访问传入到构造函数中的原始数据。稳妥构造函数模式提供的这种安全性,使得它非常适合在某些安全执行环境——例如,ADsafe(www.adsafe.org)和 Caja(http://code.google.com/p/google-caja/)提供的环境——下使用。

时间: 2024-10-25 06:26:01

javascript设计模式理论和示例深入分析(下)的相关文章

javascript设计模式理论和示例深入分析(上)

                              此文详细剖析的设计模式理论,特别是原型设计模式,帮助在遇到实际项目中提供理论指导和分析.      虽然 Object 构造函数或对象字面量都可以用来创建单个对象,但这些方式有个明显的缺点:使用同一个接口创建很多对象,会产生大量的重复代码.为解决这个问题,人们开始使用工厂模式的一种变体. 6.2.1 工厂模式 工厂模式是软件工程领域一种广为人知的设计模式,这种模式抽象了创建具体对象的过程 , 考虑到在 ECMAScript 中无法创建类

Javascript设计模式理论与编程实战之简单工厂模式_javascript技巧

阅读目录 基本介绍 举例说明 总结说明 简单工厂模式是由一个方法来决定到底要创建哪个类的实例, 而这些实例经常都拥有相同的接口. 这种模式主要用在所实例化的类型在编译期并不能确定, 而是在执行期决定的情况. 说的通俗点,就像公司茶水间的饮料机,要咖啡还是牛奶取决于你按哪个按钮. 简单工厂模式在创建ajax对象的时候也非常有用. 通常我们创建对象最常规的方法就是使用new关键字调用构造函数,这会导致对象之间的依赖性.工厂模式是一种有助于消除类之间依赖性的设计模式,它使用一个方法来决定要实例化哪一个

Javascript设计模式理论与实战:观察者模式

观察者模式主要应用于对象之间一对多的依赖关系,当一个对象发生改变时,多个对该对象有依赖的其他对象也会跟着做出相应改变,这就非常适合用观察者模式来实现.使用观察者模式可以根据需要增加或删除对象,解决一对多对象间的耦合关系,使程序更易于扩展和维护. 基础知识 观察者模式定义了对象间的一种一对多依赖关系,每当一个对象发生改变时,其相关依赖对象皆得到通知并被进行相应的改变.观察者模式又叫做发布-订阅 模式.生活中有很多类似的关系,比如微信公众号订阅,多个读者订阅一个微信公众号,一旦公众号有更新,多个读者

Javascript设计模式理论与实战:简单工厂模式

通常我们创建对象最常规的方法就是使用new关键字调用构造函数,这会导致对象之间的依赖性.工厂模式是一种有助于消除类之间依赖性的设计模式,它使用一个方法来决定要实例化哪一个类.本文详细介绍了简单工厂模式的理论,并且举例说明了简单工厂模式的具体应用. 基本介绍 简单工厂模式是工厂模式中最基本的一种.通过定义一个工厂类,根据参数实例化具体的某个产品类. 举例说明 我们举个例子进行说明:假设我们开发一个旅游行业网站,网站上面销售机票,酒店等产品.一个用户准备购买一张机票.我们可以定义相关类如下: var

Javascript设计模式理论与实战:桥接模式

桥接模式将抽象部分与实现部分分离开来,使两者都可以独立的变化,并且可以一起和谐地工作.抽象部分和实现部分都可以独立的变化而不会互相影响,降低了代码的耦合性,提高了代码的扩展性. 基本理论 桥接模式定义:将抽象部分与它的实现部分分离,使它们都可以独立地变化. 桥接模式主要有4个角色组成: (1)抽象类 (2)扩充抽象类 (3)实现类接口 (4)具体实现类 根据javascript语言的特点,我们将其简化成2个角色: (1)扩充抽象类 (2)具体实现类 怎么去理解桥接模式呢?我们接下来举例说明 桥接

javascript设计模式中的工厂模式示例

 这篇文章主要介绍了javascript设计模式中的工厂模式示例讲解,需要的朋友可以参考下 javaScript工厂方式原始的方式   因为对象的属性可以在对象创建后动态定义,这在 JavaScript 最初引入时都会编写类似下面的代码   代码如下: var oCar = new Object; oCar.color = "blue"; oCar.doors = 4; oCar.mpg = 25; oCar.showColor = function() {   alert(this.

常用的Javascript设计模式

<Practical Common Lisp>的作者 Peter Seibel 曾说,如果你需要一种模式,那一定是哪里出了问题.他所说的问题是指因为语言的天生缺陷,不得不去寻求和总结一种通用的解决方案. 不管是弱类型或强类型,静态或动态语言,命令式或说明式语言.每种语言都有天生的优缺点.一个牙买加运动员, 在短跑甚至拳击方面有一些优势,在练瑜伽上就欠缺一些. 术士和暗影牧师很容易成为一个出色的辅助,而一个背着梅肯满地图飞的敌法就会略显尴尬. 换到程序中, 静态语言里可能需要花很多功夫来实现装饰

《JavaScript设计模式》——第9章 JavaScript设计模式9.1 Constructor(构造器)模式

第9章 JavaScript设计模式 在本章中,我们将探索一些经典与现代设计模式的JavaScript实现. 开发人员通常想知道他们是否应该在工作中使用一种"理想"的模式或模式集.这个问题没有明确的唯一答案,我们研究的每个脚本和 Web 应用程序可能都有它自己的个性化需求,我们需要思考模式的哪些方面能够为实现提供实际价值. 例如,一些项目可能会受益于观察者模式提供的解耦好处(这可以减少应用程序的某些部分对彼此的依赖度),而有些项目可能只是因为太小,而根本无需考虑解耦. 也就是说,一旦我

《JavaScript设计模式》——9.12 Decorator(装饰者)模式

9.12 Decorator(装饰者)模式 Decorator是一种结构型设计模式,旨在促进代码复用.与Mixin相类似,它们可以被认为是另一个可行的对象子类化的替代方案. 通常,Decorator提供了将行为动态添加至系统的现有类的能力.其想法是,装饰本身对于类原有的基本功能来说并不是必要的:否则,它就可以被合并到超类本身了. 装饰者可以用于修改现有的系统,希望在系统中为对象添加额外的功能,而不需要大量修改使用它们的底层代码.开发人员使用它们的一个共同原因是,应用程序可能包含需要大量不同类型对