.NET设计模式系列文章
(薛敬明的专栏)
乐在其中设计模式(C#)
C#设计模式（4）－Simple Factory Pattern
http://www.cnblogs.com/zhenyulu/articles/36462.html
工厂模式专门负责将大量有共同接口的类实例化。工厂模式可以动态决定将哪一个类实例化，不必事先知道每次要实例化哪一个类。工厂模式有以下几种形态：
- 简单工厂（Simple Factory）模式
- 工厂方法（Factory Method）模式
- 抽象工厂（Abstract Factory）模式
一、 简单工厂（Simple Factory）模式
Simple Factory模式根据提供给它的数据，返回几个可能类中的一个类的实例。通常它返回的类都有一个公共的父类和公共的方法。
Simple Factory模式实际上不是GoF 23个设计模式中的一员。
二、 Simple Factory模式角色与结构：
工厂类角色Creator (LightSimpleFactory)：工厂类在客户端的直接控制下（Create方法）创建产品对象。
抽象产品角色Product (Light)：定义简单工厂创建的对象的父类或它们共同拥有的接口。可以是一个类、抽象类或接口。
具体产品角色ConcreteProduct (BulbLight, TubeLight)：定义工厂具体加工出的对象。
三、 程序举例：
using
System;
public
abstract
class
Light
{
public abstract void TurnOn(); public abstract void TurnOff();
}
public
class
BulbLight : Light
{ public override void TurnOn()
{ Console.WriteLine("Bulb Light is Turned on");
} public override void TurnOff() { Console.WriteLine("Bulb Light is Turned off"); }}
public
class
TubeLight : Light
{ public override void TurnOn() { Console.WriteLine("Tube Light is Turned on"); } public override void TurnOff() { Console.WriteLine("Tube Light is Turned off"); }}
public
class
LightSimpleFactory
{ public Light Create(string LightType) { if(LightType == "Bulb") return new BulbLight(); else if(LightType == "Tube") return new TubeLight(); else return null; }}
public
class
Client
{ public static void Main() { LightSimpleFactory lsf = new LightSimpleFactory(); Light l = lsf.Create("Bulb"); l.TurnOn(); l.TurnOff(); Console.WriteLine("-----------------"); l = lsf.Create("Tube"); l.TurnOn(); l.TurnOff(); }}
四、 Simple Factory模式演化
Simple Factory模式演化（一）
除了上面的用法外，在有些情况下Simple Factory可以由抽象产品角色扮演，一个抽象产品类同时是子类的工厂。
程序举例：
using
System;
public
class
Light
{ public virtual void TurnOn() { } public virtual void TurnOff() { } public static Light Create(string LightType) { if(LightType == "Bulb") return new BulbLight(); else if(LightType == "Tube") return new TubeLight(); else return null; }}
public
class
BulbLight : Light
{ public override void TurnOn() { Console.WriteLine("Bulb Light is Turned on"); } public override void TurnOff() { Console.WriteLine("Bulb Light is Turned off"); }}
public
class
TubeLight : Light
{ public override void TurnOn() { Console.WriteLine("Tube Light is Turned on"); } public override void TurnOff() { Console.WriteLine("Tube Light is Turned off"); }}
public
class
Client
{ public static void Main() { Light l = Light.Create("Bulb"); l.TurnOn(); l.TurnOff(); Console.WriteLine("-----------------"); l = Light.Create("Tube"); l.TurnOn(); l.TurnOff(); }}
Simple Factory模式演化（二）
三个角色全部合并：
与单件模式（Singleton）相近，但是有区别。
五、 优点与缺点：
优点：
工厂类含有必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实例，客户端可以免除直接创建产品对象的责任，而仅仅"消费"产品。简单工厂模式通过这种做法实现了对责任的分割。
缺点：
当产品有复杂的多层等级结构时，工厂类只有自己，以不变应万变，就是模式的缺点。因为工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统都要受到影响。
同时，系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，有可能造成工厂逻辑过于复杂。
另外，简单工厂模式通常使用静态工厂方法，这使得无法由子类继承，造成工厂角色无法形成基于继承的等级结构。
参考文献：
阎宏，《Java与模式》，电子工业出版社
[美]James W. Cooper，《C#设计模式》，电子工业出版社
[美]Alan Shalloway James R. Trott，《Design Patterns Explained》，中国电力出版社
[美]Robert C. Martin，《敏捷软件开发－原则、模式与实践》，清华大学出版社
[美]Don Box, Chris Sells，《.NET本质论 第1卷：公共语言运行库》，中国电力出版社
.NET设计模式(1): 简单工厂模式
http://www.cnblogs.com/anlyren/archive/2008/01/25/simple_Factory_Pattern.html
最近一直在看设计模式，想把自己的学习笔记与大家分享一下，如果能帮助大家的话，我会非常高兴，同时也欢迎大家指出里面的不足。园子里其实关于此类文章已经很多了，如果dudu感觉放在首页欠妥的话，可以调一下。
简单工厂模式（Simple Factory Pattern）
介绍：简单工厂模式不能说是一个设计模式，说它是一种编程习惯可能更恰当些。因为它至少不是Gof23种设计模式之一。但它在实际的编程中经常被用到，而且思想也非常简单，可以说是工厂方法模式的一个引导，所以我想有必要把它作为第一个讲一下。
引入：
我们在编程的时候，每当"new"一个对象之后，这个对象就依赖于这个类了。如果在后期的维护过程中由于某些原因需要修改一下这个类，则唯一的做法就是打开源代码，进行修改，修改所有与这个对象有关的操作。这对我们是非常不利的。
问题出来了：对象不能应对“具体实例化类型”的变化
解决思路：套用一下李建忠李老师的话，封装变化点，哪里变化，封装哪里。在这个例子中，要实例化的类变了，就将实例化这个操作封装起来，我们可以把"new"这个操作移交一个具体的类，由它去负责根据我们的条件创建具体类的实例，也就是下面要说的“简单工厂模式”。
定义：
专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类或接口。简单工厂模式又称为静态工厂方法（Static Factory Method）模式，属于类的创建型模式，通常根据一个条件（参数）来返回不同的类的实例。
意图：
提供一个类，由它负责根据一定的条件创建某一具体类的实例
参与者：
- 工厂角色（Creator）
是简单工厂模式的核心，它负责实现创建所有具体产品类的实例。工厂类可以被外界直接调用，创建所需的产品对象。 - 抽象产品角色（Product）
是所有具体产品角色的父类，它负责描述所有实例所共有的公共接口。 - 具体产品角色（Concrete Product）
继承自抽象产品角色，一般为多个，是简单工厂模式的创建目标。工厂类返回的都是该角色的某一具体产品。
UML图：
现实生活中例子：
每次参加不同的聚会或者与不同的人见面，可能穿的衣服是不一样的，比如，你今天上午要与你的一个新客户见面，你可能会对你的老婆说：老婆，给拿件商务装（参数），我要去见我的一个客户，你老婆（工厂类）接到你的请求（商务装参数）后，从衣柜中取出一件商务装（具体产品），交给你。整个过程就完成了。
分析：
你可能根据不同的条件，要的衣服是不一样的，但要的衣服都是已经在你的衣柜中存在的。并且，每件上衣它们都属于同一种抽象，即它们可以从一个抽象类或接口中继承，这此衣服各自都有一定特征，这些都是条件。然后你要的时候，就可以向你老婆说一种特征，她就会根据这个特征为你服务了。这就是典型的简单工厂模式的应用。
抽象产品类代码
/// <summary>2
/// 抽象产品类:上衣3
/// </summary>
4
public
interface
ICoat5
{6
void GetYourCoat();7
}
非常简单，是吧？这里我只是举一个仅仅能说明问题的例子，在具体的项目中，可能是很复杂的哦。。
具体产品类代码
namespace
SimpleFactory2
{3
/// <summary>4
/// 具体产品类：商务上衣5
/// </summary>6
public class BusinessCoat:ICoat7
{8
public void GetYourCoat()9
{10
Console.WriteLine("商务上衣");11
}12
}13
14
/// <summary>15
/// 具体产品类：时尚上衣16
/// </summary>17
public class FashionCoat : ICoat18
{19
/// <summary>20
/// 实现ICoat中定义的方法21
/// </summary>22
/// <returns></returns>23
public void GetYourCoat()24
{25
Console.WriteLine("时尚上衣");26
}27
}28
}
简单工厂模式中最核心的部分：工厂类
namespace
SimpleFactory2
{3
/// <summary>4
/// 简单工厂模式中的核心部分:工厂类5
/// </summary>6
public class Factory7
{8
public ICoat CreateCoat(string styleName)9
{10
switch (styleName.Trim().ToLower())11
{12
case "business":13
return new BusinessCoat();14
case "fashion":15
return new FashionCoat();16
default :17
throw new Exception("还没有你要的那种衣服");18
}19
}20
}21
}
再看一下客户在调用的时候的代码
/// <summary>2
/// 客户类3
/// </summary>
4
class
Client5
{6
static void Main(string[] args)7
{8
ICoat food;9
try10
{11
Factory factory = new Factory();12
13
Console.Write("我要的是时尚上衣\t");14
food = factory.CreateCoat("fashion");15
food.GetYourCoat();16
17
}18
catch (Exception ex)19
{20
Console.WriteLine(ex.Message);21
}22
}23
}
到这里，代码就完成了。
在客户端的代码中有我们就可以根据具体的参数，返回我们希望返回的对象，将"new"操作推迟到工厂类中实现。
这里，参数我直接写上了，我们其实可以将这个参数写到一个xml文件中，如app.config文件中，动态的读出来，需要穿另外一种衣服了，只需要打开app.config文件，修改里面的值就行了，不需要项目重新编译。这样这个小程序就能够适应一定的变化了（在上传上去的代码中我会修改一下）。其实它也是设计模式正要解决的问题，在不修改代码的情况下，使项目能够适应一定的客户需求变化。注意，是一定的，并非全部。
优点：
- 简单工厂模式能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。通过它，外界可以从直接创建具体产品对 象的尴尬局面中摆脱出来。
- 外界与具体类隔离开来，偶合性低。
- 明确区分了各自的职责和权力，有利于整个软件体系结构的优化。
缺点：
- 工厂类集中了所有实例的创建逻辑，容易违反GRASPR的高内聚的责任分配原则
- 虽然简单工厂模式能够适应一定的变化，但是它所能解决的问题是远远有限的。它所能创建的类只能是事先教考虑到的，如果需要添加新的类，则就需要改变工厂类了。（这个问题在下一个工厂方法模式将得到很好的解决）
应用情景
- 工厂类负责创建的对象比较少
- 客户只知道传入了工厂类的参数，对于始何创建对象（逻辑）不关心
参考资料
- 《深入浅出设计模式(C#/Java版) 》 清华大学出版社
- MSDN Webcast C#面向对象设计模式纵横谈 李建忠老师
源程序下载：/Files/anlyren/SimpleFactory.rar
简单工厂模式(UML解析)
http://blog.csdn.net/weiwenlongll/article/details/6918164简单工厂模式解释：
简单工厂模式（Simple Factory Pattern）属于类的创新型模式，又叫静态工厂方法模式（Static FactoryMethod Pattern）,是通过专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。
简单工厂模式的UML图：
简单工厂模式中包含的角色及其相应的职责如下：
工厂角色（Creator）：这是简单工厂模式的核心，由它负责创建所有的类的内部逻辑。当然工厂类必须能够被外界调用，创建所需要的产品对象。
抽象（Product）产品角色：简单工厂模式所创建的所有对象的父类，注意，这里的父类可以是接口也可以是抽象类，它负责描述所有实例所共有的公共接口。
具体产品（Concrete Product）角色：简单工厂所创建的具体实例对象，这些具体的产品往往都拥有共同的父类。
简单工厂模式深入分析：
简单工厂模式解决的问题是如何去实例化一个合适的对象。
简单工厂模式的核心思想就是：有一个专门的类来负责创建实例的过程。
具体来说，把产品看着是一系列的类的集合，这些类是由某个抽象类或者接口派生出来的一个对象树。而工厂类用来产生一个合适的对象来满足客户的要求。
如果简单工厂模式所涉及到的具体产品之间没有共同的逻辑，那么我们就可以使用接口来扮演抽象产品的角色；如果具体产品之间有功能的逻辑或，我们就必须把这些共同的东西提取出来，放在一个抽象类中，然后让具体产品继承抽象类。为实现更好复用的目的，共同的东西总是应该抽象出来的。
在实际的的使用中，抽闲产品和具体产品之间往往是多层次的产品结构，如下图所示：
简单工厂模式使用场景分析及代码实现：
GG请自己的女朋友和众多美女吃饭，但是GG自己是不会做饭的或者做的饭很不好，这说明GG不用自己去创建各种食物的对象；各个美女都有各自的爱好，到麦当劳后她们喜欢吃什么直接去点就行了，麦当劳就是生产各种食物的工厂，这时候GG不用自己动手，也可以请这么多美女吃饭，所要做的就是买单O(∩_∩)O哈哈~,其UML图如下所示：
实现代码如下：
新建立一个食物的接口：
| package com.diermeng.designPattern.SimpleFactory;
/* * 产品的抽象接口 */ public interface Food { /* * 获得相应的食物 */ public void get(); } |
接下来建立具体的产品：麦香鸡和薯条
| package com.diermeng.designPattern.SimpleFactory.impl; import com.diermeng.designPattern.SimpleFactory.Food;
/* * 麦香鸡对抽象产品接口的实现 */ public class McChicken implements Food{ /* * 获取一份麦香鸡 */ public void get(){ System.out.println("我要一份麦香鸡"); } } |
| package com.diermeng.designPattern.SimpleFactory.impl; import com.diermeng.designPattern.SimpleFactory.Food;
/* * 薯条对抽象产品接口的实现 */ public class Chips implements Food{ /* * 获取一份薯条 */ public void get(){ System.out.println("我要一份薯条"); } } |
现在建立一个食物加工工厂：
| package com.diermeng.designPattern.SimpleFactory.impl; import com.diermeng.designPattern.SimpleFactory.Food;
public class FoodFactory {
public static Food getFood(String type) throws InstantiationException, IllegalAccessException, ClassNotFoundException { if(type.equalsIgnoreCase("mcchicken")) { return McChicken.class.newInstance();
} else if(type.equalsIgnoreCase("chips")) { return Chips.class.newInstance(); } else { System.out.println("哎呀！找不到相应的实例化类啦！"); return null; }
} } |
最后我们建立测试客户端：
| package com.diermeng.designPattern.SimpleFactory.client; import com.diermeng.designPattern.SimpleFactory.Food; import com.diermeng.designPattern.SimpleFactory.impl.FoodFactory;
/* * 测试客户端 */ public class SimpleFactoryTest { public static void main(String[] args) throws InstantiationException, IllegalAccessException, ClassNotFoundException {
//实例化各种食物 Food mcChicken = FoodFactory.getFood("McChicken"); Food chips = FoodFactory.getFood("Chips"); Food eggs = FoodFactory.getFood("Eggs");
//获取食物 if(mcChicken!=null){ mcChicken.get(); } if(chips!=null){ chips.get(); } if(eggs!=null){ eggs.get(); }
} } |
输出的结果如下：
| 哎呀！找不到相应的实例化类啦！ 我要一份麦香鸡 我要一份薯条 |
简单工厂模式的优缺点分析：
优点：工厂类是整个模式的关键所在。它包含必要的判断逻辑，能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。用户在使用时可以直接根据工厂类去创建所需的实例，而无需了解这些对象是如何创建以及如何组织的。有利于整个软件体系结构的优化。
缺点：由于工厂类集中了所有实例的创建逻辑，这就直接导致一旦这个工厂出了问题，所有的客户端都会受到牵连；而且由于简单工厂模式的产品室基于一个共同的抽象类或者接口，这样一来，但产品的种类增加的时候，即有不同的产品接口或者抽象类的时候，工厂类就需要判断何时创建何种种类的产品，这就和创建何种种类产品的产品相互混淆在了一起，违背了单一职责，导致系统丧失灵活性和可维护性。而且更重要的是，简单工厂模式违背了“开放封闭原则”，就是违背了“系统对扩展开放，对修改关闭”的原则，因为当我新增加一个产品的时候必须修改工厂类，相应的工厂类就需要重新编译一遍。
总结一下：简单工厂模式分离产品的创建者和消费者，有利于软件系统结构的优化；但是由于一切逻辑都集中在一个工厂类中，导致了没有很高的内聚性，同时也违背了“开放封闭原则”。另外，简单工厂模式的方法一般都是静态的，而静态工厂方法是无法让子类继承的，因此，简单工厂模式无法形成基于基类的继承树结构。
简单工厂模式的实际应用简介：
作为一个最基本和最简单的设计模式，简单工厂模式却有很非常广泛的应用，我们这里以Java中的JDBC操作数据库为例来说明。
JDBC是SUN公司提供的一套数据库编程接口API，它利用Java语言提供简单、一致的方式来访问各种关系型数据库。Java程序通过JDBC可以执行SQL语句，对获取的数据进行处理，并将变化了的数据存回数据库，因此，JDBC是Java应用程序与各种关系数据进行对话的一种机制。用JDBC进行数据库访问时，要使用数据库厂商提供的驱动程序接口与数据库管理系统进行数据交互。
客户端要使用使用数据时，只需要和工厂进行交互即可，这就导致操作步骤得到极大的简化，操作步骤按照顺序依次为：注册并加载数据库驱动，一般使用Class.forName();创建与数据库的链接Connection对象；创建SQL语句对象preparedStatement(sql)；提交SQL语句，根据实际情况使用executeQuery()或者executeUpdate()；显示相应的结果；关闭数据库。
简单工厂模式(基于WF的网页新闻内容下载)
http://teroy.diandian.com/post/2012-01-14/16553344
记得第一次接触设计模式是从园子上的一篇博文看起的。
http://www.cnblogs.com/anlyren/archive/2008/01/25/simple_Factory_Pattern.html
这篇博文将简单工厂模式讲得即简练又通俗，算是给了我一次初窥设计模式之美的机会，不过那时还是流于字面上的肤浅理解，直到后来的一次小项目经历，才有机会派上用场。
项目截图：
项目概况：实现基于WF的网页新闻内容下载(数据采集部分)
项目需求：支持多个主流网站门户的新闻内容下载
需求分析：（因为个人想阐述一下简单工厂模式的运用，所以一些细节，如页面内容如何下载，我就略去文字了）各个门户网站的采集标签既有不同点又有相同点。相同点是页面标题，css，charset，直接用web相同的标签正则匹配，不同点是页面新闻主体内容，需要用到不同的标签。
代码设计：
基类：
子类：
这样处理的话就能实现代码重用以及很好的扩展性，可以针对不同的门户网实现不同的子类。（其实这里有一点处理得很不好，就是那些匹配的采集规则写死在代码里面，这样就造成了紧耦合，要实现修改规则就只能修改源代码并再次编译代码，这并不是一个友善的处理。改进方法：可以用XML文件存储这些匹配规则，再建立一个类，可以做映射处理，从类中读取出XML文件中的规则。这样，要修改规则，只需修改XML文件，并不需要对代码再次编译，可维护性以及扩展性得到了很大的提升。）
工厂封装：
（这里又出现了一些弊端，工厂封装应该专注于实例化对象，实现单一职责原则，而不应该把方法也写在同一个类中。改进方法：工厂应该专注于实例化对象的操作，在此之为建立另一个类实现业务逻辑，就是将原本在同一个类的代码进行分离。而且，对于命名也应该遵循一定的准则，特别是工厂的命名。如：DataFactory.CreateData（）的静态方法。）
业务逻辑：
在客户端就只用这两句代码就实现了数据采集。
总结：简单工厂关心的就是如何去实例化对象的问题。
后续：
一次滥用简单工厂模式的反思：这次面对的问题是电子商务的的电子支付平台问题
基类：
子类：
枚举：
工厂：
扫一扫
882
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
