51CTO旗下网站
Javascript设计模式理论与实战：简单工厂模式
通常我们创建对象最常规的方法就是使用new关键字调用构造函数，这会导致对象之间的依赖性。工厂模式是一种有助于消除类之间依赖性的设计模式，它使用一个方法来决定要实例化哪一个类。本文详细介绍了简单工厂模式的理论，并且举例说明了简单工厂模式的具体应用。
作者：小灰狼的脑瓜来源：| 09:43
通常我们创建对象最常规的方法就是使用new关键字调用构造函数，这会导致对象之间的依赖性。工厂模式是一种有助于消除类之间依赖性的设计模式，它使用一个方法来决定要实例化哪一个类。本文详细介绍了简单工厂模式的理论，并且举例说明了简单工厂模式的具体应用。
简单工厂模式是工厂模式中最基本的一种。通过定义一个工厂类，根据参数实例化具体的某个产品类。
我们举个例子进行说明：假设我们开发一个旅游行业网站，网站上面销售机票，酒店等产品。一个用户准备购买一张机票。我们可以定义相关类如下：
var&productEnums&=&{&&&&&flight:&&flight&,&&&&&hotel:&&hotel&&};&function&Flight()&{&&&&&console.log(&This&is&Flight&);&}&function&Hotel()&{&&&&&console.log(&This&is&Hotel&);&}&function&User()&{&&&&&this.shopCart&=&[];&}&User.prototype&=&{&&&&&constructor:&User,&&&&&order:&function&(productType)&{&&&&&&&&&var&product&=&null;&&&&&&&&&switch&(productType)&{&&&&&&&&&&&&&case&productEnums.flight:&&&&&&&&&&&&&&&&&product&=&new&Flight();&&&&&&&&&&&&&case&productEnums.hotel:&&&&&&&&&&&&&&&&&product&=&new&Hotel();&&&&&&&&&&&&&default:&&&&&&&&&}&&&&&&&&&this.shopCart.push(product);&&&&&}&}&var&user&=&new&User();&user.order(productEnums.flight);&
这段代码定义了三个类：用户类User，机票类Flight，酒店类Hotel，其中User包含预订方法。用户预订的时候直接传入产品类型即可。 这段代码乍一看没什么问题，但是需求和业务是随时变化的，如果公司业务扩展，增加了签证业务，我们就要去修改User类来保证它支持签证。我们当然可以这 么做，但直接去修改User类有什么不好呢，有没有更好的方法呢？
首先要说的是User类，这个类是表示用户类，而用户类本质上跟具体的某一类业务是无关的，也就是说，业务有可能随时增加，但是用户关于业务方面的 代码也就是创建产品订单。新增的签证业务本质上和已经存在的机票和酒店没有什么区别，如果每增加一种业务就要去修改User类，这对代码的稳定性和可维护 性大大的不好，更好的解决方法是有一个专门的创建订单的类在管理不同的业务，这个类就是简单工厂。
我们修改代码如下：
var&productFactory&=&(function&()&{&&&&&var&productFactories&=&{&&&&&&&&&&flight&:&function&()&{&&&&&&&&&&&&&return&new&Flight();&&&&&&&&&},&&&&&&&&&&hotel&:&function&()&{&&&&&&&&&&&&&return&new&Hotel();&&&&&&&&&}&&&&&};&&&&&&return&{&&&&&&&&&createProduct:&function&(productType)&{&&&&&&&&&&&&&return&productFactories[productType]();&&&&&&&&&}&&&&&}&})();&User.prototype&=&{&&&&&constructor:&User,&&&&&order:&function&(productType)&{&&&&&&&&&this.shopCart.push(productFactory.createProduct(productType));&&&&&}&}&
这段代码主要修改的地方有两点：
（1）增加了一个产品工厂，根据不同的产品类型返回不同的对象
（2）修改User类的order方法为调用工厂类中的创建产品方法。
这样做的好处是：
（1）使User的order方法更加专注，只做预订产品这一功能，而提取创建产品订单到专门的工厂类中，代码更简洁清晰
（2）一个专门管理product的factory，添加新产品很容易，不用再去修改User类
简单工厂模式的主要特点是将对象的创建和使用进行了分离，主要有3个部分组成：
1.对象使用类，该类是被工厂创造出来的使用者，与对象的种类和创建过程无关
2.工厂类，工厂类根据传入的参数创建不同的对象并返回给对象使用类，包含了不同对象的创建过程，如果有不同的对象，则要修改该类
3.对象类，不同业务产生的不同类，就是工厂生产的产品
简单工厂模式优点
1.工厂类集中了所有对象的创建，便于对象创建的统一管理
2.对象的使用者仅仅是使用产品，实现了单一职责
3.便于扩展，如果新增了一种业务，只需要增加相关的业务对象类和工厂类中的生产业务对象的方法，不需要修改其他的地方。
1.需要根据不同参数产生不同实例，这些实例有一些共性的场景
2.使用者只需要使用产品，不需要知道产品的创建细节
注意：除非是适用场景，否则不可滥用工厂模式，会造成代码的复杂度。
原文地址：【责任编辑： TEL：（010）】
大家都在看猜你喜欢
热点头条关注头条头条
24H热文一周话题本月最赞
讲师：225420人学习过
讲师：51174人学习过
讲师：12572人学习过
精选博文论坛热帖下载排行
本书是一本非常全面地讲述黑客入侵主动防御技术的网络安全工具书。本书的重点是介绍黑客的攻击手段和提供相应的主动防御保护措施，在组织结...
订阅51CTO邮刊luozhonglan
阅读(14133)
1. 简单工厂模式
如何理解简单工厂，工厂方法， 抽象工厂三种设计模式？
简单工厂的生活场景，卖早点的小摊贩，他给你提供包子，馒头，地沟油烙的煎饼等，小贩是一个工厂，它生产包子，馒头，地沟油烙的煎饼。该场景对应的UML图如下所示：
图1：简单工厂模式UML图
简单工厂模式的参与者：
工厂（Factory）角色：接受客户端的请求，通过请求负责创建相应的产品对象。
抽象产品（Abstract Product）角色:
是工厂模式所创建对象的父类或是共同拥有的接口。可是抽象类或接口。
具体产品（ConcreteProduct）对象：工厂模式所创建的对象都是这个角色的实例。
简单工厂模式的演变：
1.）当系统中只有唯一的产品时，可以省略抽象产品，如图1所示。这样，工厂角色与具体产品可以合并。
简单工厂模式的优缺点：
1.）工厂类含有必要的创建何种产品的逻辑，这样客户端只需要请求需要的产品，而不需要理会产品的实现细节。
2.）工厂类只有一个，它集中了所有产品创建的逻辑，它将是整个系统的瓶颈，同时造成系统难以拓展。
3.）简单工厂模式通常使用静态工厂方法，这使得工厂类无法由子类继承，这使得工厂角色无法形成基于继承的等级结构。
2.&工厂方法模式
工厂方法使用OOP的多态性，将工厂和产品都抽象出一个基类，在基类中定义统一的接口，然后在具体的工厂中创建具体的产品。工厂方法的生活场景，联合利华要生产“夏士莲”和“清扬”两款洗发水，它会建一个生产“夏士莲”的工厂和一个生产“清扬”的工厂。
图2：工厂方法的UML图
工厂方法模式中的参与者：
抽象工厂角色：与应用程序无关，任何在模式中创建对象的工厂必须实现这个接口。
具体工厂角色：实现了抽象工厂接口的具体类，含有与引用密切相关的逻辑，并且受到应用程序的调用以创建产品对象。
抽象产品角色：工厂方法所创建产品对象的超类型，也就是产品对象的共同父类或共同拥有的接口。
具体产品角色：这个角色实现了抽象产品角色所声名的接口。工厂方法所创建的每个具体产品对象都是某个具体产品角色的实例。
工厂方法的优缺点：
1.）降低了工厂类的内聚，满足了类之间的层次关系，又很好的符合了面向对象设计中的单一职责原则，这样有利于程序的拓展，如图三所示：
图3：工厂方法的拓展UML图
总结：把“共性”提取出来，根据各自的“个性”建立各自的继承共性的实现
3. 抽象工厂设计模式
所谓抽象工厂是指一个工厂等级结构可以创建出分属于不同产品等级结构的一个产品族中的所有对象，以创建Unix控件和Windows控件为例说明，我们需要一个抽象工厂下面有两个子工厂，一个叫做UnixFactory,用于生产Unix族控件，一个叫做WinFactory，用于生产Win族控件。抽象工厂与工厂方法的区别是，工厂方法中的具体工厂一般只生产一个或几个控件对象，而抽象工厂中的具体工厂生产的是一族控件对象。如图4所示。
图4：抽象工厂设计模式UML图
抽象工厂中的参与者：
担任这个角色的是工厂方法模式的核心，它是与应用系统商业逻辑无关的。
这个角色直接在客户端的调用下创建产品的实例。这个角色含有选择合适的产品对象的逻辑，而这个逻辑是与应用系统的商业逻辑紧密相关的。
担任这个角色的类是工厂方法模式所创建的对象的父类，或它们共同拥有的接口。
抽象工厂模式所创建的任何产品对象都是某一个具体产品类的实例。这是客户端最终需要的东西，其内部一定充满了应用系统的商业逻辑。
抽象工厂的使用场景：
一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有形态的工厂模式都是重要的。 这个系统有多于一个的产品族，而系统只消费其中某一产品族。 同属于同一个产品族的产品是在一起使用的，这一约束必须在系统的设计中体现出来。 系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于实现。
抽象工厂模式与工厂方法模式的区别
工厂方法模式：每个抽象产品派生多个具体产品类，每个抽象工厂类派生多个具体工厂类，每个具体工厂类负责一个具体产品的实例创建；&
抽象工厂模式：每个抽象产品派生多个具体产品类，每个抽象工厂派生多个具体工厂类，每个具体工厂负责多个（一系列）具体产品的实例创建。&
//在UIKit框架下，我们用工厂方法和抽象工厂两种设计模式分别实现了两份Demo， 不理解两种设计模式该如何实现的朋友可以到这里下载： &刷不出来，以后补上！
参考文章：
简单工厂：&
工厂方法：
抽象工厂：
阅读排行榜没有更多推荐了，
不良信息举报
举报内容：
PHP简单工厂模式、工厂方法模式和抽象工厂模式比较
举报原因：
原文地址：
原因补充：
最多只允许输入30个字
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！Objective-C类族和工厂模式
招聘信息：
相信大家都了解GoF的《Design Patterns》中提到的23种设计模式，其中将常见的设计模式分为三大类：创建型模式、行为型模式、结构型模式。而在《Clean Code》中也提到建造酒店的例子，系统中对象的构建和使用应当分离开，那么应该怎么构建对象更加整洁和符合使用场景就很重要。在iOS的系统类库中也有一种方式使得开发者不必关注类中具体的存储实现，但可以根据不同需求场景创建出合适的对象来。比如Foudation中的NSArray、UIkit中的UIButton。本文结合几种工厂设计模式的原理，对Objective-C类族的概念做一下简要的整理。0. 三种工厂其实除了《Design Patterns》中提到的Factory Method和Abstract Factory，常提到的还有另一种工厂模式Simple Factory。在简单工厂中，产品有一个统一的interface，而可以有不同implementation，同时有一个（通常是仅有一个）工厂对象。需要产品的时候，工厂会根据已有条件做switch，选择一种产品实现，构建一个实例出来。这种设计将产品的抽象和实现分离开来，可以针对统一的产品接口进行通信，而不必特意关注具体实现的不同。对于产品类别的扩充也是可以的，但每增加一个产品，都需要修改工厂的逻辑，有一定维护成本。工厂方法更进一步，将工厂也抽象出来，进行接口、实现分离。这样具体工厂和具体产品可以对应着同时扩充，而不需要修改现有逻辑。当然，使用者也许在不同场景要在一定程度上自己对应的工厂选择（这个总要有人知道，不可避免）。抽象工厂相对于工厂方法主要是对整个产品类的体系进行了横向扩充，构成一个更为完整的系统。1. Objective-C的类族（Class Cluster）做iOS开发的朋友们一定用过NSNumber的numberWith…方法。但大家有可能都不知道NSNumber这样的方法调用返回的不是NSNumber类本身的对象，这正是Objective-C类族的微妙之处。如上图所示，Number的概念很大。而实际上NSNumber实际上是有很多隐藏的子类的，而我们通过NSNumber的numberWith…方法得到的对象正是其子类的对象，但对于使用者几乎可以不必知道这一点，只要知道它是一个NSNumber对象就OK了。“Simple Concept and Simple Interface”，这正是苹果设计类族的初衷，也是类族的优点所在。可以想象我们要用整数作为参数拿到一个NSNumber对象和一个布尔值参数拿到的NSNumber对象是不同的，这略微有些类似于switch逻辑（虽然是通过不同的方法），根据不同的条件提供不同的子类对象，而这一切都集中声明在公共接口类NSNumber中。我们很容易联想到上面提到的Simple Factory（简单工厂）设计模式。没错，与简单工厂类似，类族的一个缺点也显现出来，那就是已有的类族不好扩展。比如你想NSNumber再多支持一种情况，这个恐怕很难。好在这些系统的类库已经将大部分可能都做进去了，考虑得比较完善，通常你只是去用就可以了。2. 类族的子类扩展了解了类族的概念，我们在实际开发当中也可以采用其方式，利用其优点。上面提到对已有类族进行子类扩展是很难的，但这不代表NSNumber、NSArray等类就没法继承了。他们还是可以有自定义的子类的。既然要做类族的子类，就要做到：· 以公共“抽象”类为父类，比如NSNumber、NSArray等，而非其子类· 提供自定义存储· 重写（覆盖）父类所有初始化方法· 重写父类中“原始”方法其中第二点最重要，系统的类族通常在父类中只是提供了各种方法声明，而自身并不提供存储，所以要自定义子类一定要提供自己的存储，一般情况下这也是自定义子类的意义所在。重写初始化方法，要遵从Objective-C初始化链的规范。而重写“原始”方法，这个要说一下。按照苹果的文档，和指定初始化方法形式类似，这些类里面的众多方法可以分为两类，“原始”方法和“衍生”方法。“原始”方法定义了这个类及对象的最基本行为，而“衍生”方法则基于这些“原始”方法进行更复杂逻辑的包装。所以，重写了“原始”方法，“衍生”方法也自然效果就不同了。除了自定义子类外，苹果官方更建议开发者用组合的方式对类族类进行包装。3. 对象所属类的判断有人会问，如果我没有特殊需求，不需要写NSArray、NSNumber的子类，是不是了解类族就没有多大意义了。这里记一下，通过了解类族概念，我们至少知道了，通过NSNumber得到的对象，不一定是（基本上就不会是）NSNumber类本身的对象。可以试验下，通过[NSNumber numberWithInt:2]和[NSNumber numberWithBool:YES]得到的对象对应的类，一个是__NSCFNumber，另一个是__NSCFBoolean。那么，如下这样的判断就不行了：id&maybeAnArray&=&/*&...&*/;
if&([maybeAnArray&class]&==&[NSArray&class])&{
&&&//&Will&never&be&hit
}需要在适当的情况下选择使用isMemberOfClass和isKindOfClass。本文到这就整理这么多，更多内容可参看：《Effective Objective-C》第9条
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
您还没有登录！请或
点击量4849点击量4404点击量3835点击量3456点击量3217点击量3180点击量3133点击量2980点击量2812
&2016 Chukong Technologies,Inc.
京公网安备89请问策略模式和工厂模式的区别
作者：用户
浏览：453 次
工厂模式抽象出共同的方法,继承接口,反射出对象,执行方法策略模式,抽象出共同的方法,继承接口,context传递继承的类,调用继承类的方法怎么感觉好像啊?为什么会区分成2种设计模式?应用场景的区别是什
问题描述工厂模式抽象出共同的方法,继承接口,反射出对象,执行方法策略模式,抽象出共同的方法,继承接口,context传递继承的类,调用继承类的方法怎么感觉好像啊?为什么会区分成2种设计模式?应用场景的区别是什么?解决方案解决方案二：楼主在哪里知道的这些名词？这些名词能帮你解决什么问题？解决方案三：工厂解决的是创建的过程策略解决的是动作更具体的说，工厂是要解决如何创建某个对象，重点在于对象，而策略不关心你对象是怎么创建的，它只关心你传入的对象，它需要用这个对象来解决问题，重点在于解决所以你完全可以用工厂创建对象，然后这个对象作为策略需要的参数解决方案四：如果你用.net中的直截了当的术语，根本不需要太多忽悠了。比如说，对象实例是可以动态创建的，例如其本质原型为Dictionary&string,Type&//....vart=(fromxindbwherex.Key==nameselectx.Value).First();varinstance=Activator.CreateInstance(t);或者比如说，委托实例是可以动态调用的，例如其原型实例为Dictionary&string,Func&int,string&&//....varf=(fromxindbwherex.Key==nameselectx.Value).First();varresult=f(1234);你可以把这些知识用到需要动态查表去创建不同类型对象或者调用预先注册的委托函数的地方，例如通过配置文件来决定运行时反射执行一些操作。《设计模式》那本书写的年代比较古老，加之作者最初是针对java的，所以技术术语非常贫乏。他们当时还不太懂什么叫做“事件、委托、反射、依赖倒置”等等术语，也没有比较高级一点的编程“语法糖”来让代码写得精简。例如c#中对于Delegate就是个语法糖，编译器自动产生复杂的类型代码、自动实现Invoke等等接口定义方法，但是编程者只用直截了当地一条代码来书写，理解上也容易。而GOF全都用比较雷人的字眼儿来命名了那些模式，也用比较雷人的代码来写那些接口和类型，所以程序员可以用来消磨时光。实际上23种模式，最多有5种就够了。解决方案五：引用3楼sp1234_maJia的回复:如果你用.net中的直截了当的术语，根本不需要太多忽悠了。比如说，对象实例是可以动态创建的，例如其本质原型为Dictionary&string,Type&//....vart=(fromxindbwherex.Key==nameselectx.Value).First();varinstance=Activator.CreateInstance(t);或者比如说，委托实例是可以动态调用的，例如其原型实例为Dictionary&string,Func&int,string&&//....varf=(fromxindbwherex.Key==nameselectx.Value).First();varresult=f(1234);你可以把这些知识用到需要动态查表去创建不同类型对象或者调用预先注册的委托函数的地方，例如通过配置文件来决定运行时反射执行一些操作。《设计模式》那本书写的年代比较古老，加之作者最初是针对java的，所以技术术语非常贫乏。他们当时还不太懂什么叫做“事件、委托、反射、依赖倒置”等等术语，也没有比较高级一点的编程“语法糖”来让代码写得精简。例如c#中对于Delegate就是个语法糖，编译器自动产生复杂的类型代码、自动实现Invoke等等接口定义方法，但是编程者只用直截了当地一条代码来书写，理解上也容易。而GOF全都用比较雷人的字眼儿来命名了那些模式，也用比较雷人的代码来写那些接口和类型，所以程序员可以用来消磨时光。实际上23种模式，最多有5种就够了。想补充一下基础知识,所以在看设计模式,不过不去了解原理,只依靠语法糖好吗?另外请教一下,您认为哪5种就够了?引用1楼jhdxhj的回复:楼主在哪里知道的这些名词？这些名词能帮你解决什么问题？我在补充基础知识和整理思路引用2楼starfd的回复:工厂解决的是创建的过程策略解决的是动作更具体的说，工厂是要解决如何创建某个对象，重点在于对象，而策略不关心你对象是怎么创建的，它只关心你传入的对象，它需要用这个对象来解决问题，重点在于解决所以你完全可以用工厂创建对象，然后这个对象作为策略需要的参数您的看法,是这些没有区别?解决方案六：设计模式只是对人们编写的代码形态上的总结，并不具指导意义看看设计模式也没什么坏处，起码你会知道：哦，原来这个还可以那么写
【云栖快讯】青年们，一起向代码致敬，来寻找第83行吧，云栖社区邀请大神彭蕾、多隆、毕玄、福贝、点评Review你的代码，参与互动者将选取50位精彩回复赠送“向代码致敬”定制T恤1件，最终成为“多隆奖”的小伙伴还将获得由阿里巴巴提供的“多隆奖”荣誉证书和奖杯。&&
弹性可伸缩的计算服务，助您降低 IT 成本，提升运维效率
40+云计算产品，6个月免费体验
稳定可靠、可弹性伸缩的在线数据库服务，全球最受欢迎的开源数据库之一
云服务器9.9元/月，大学必备