[原创]工厂模式我之见（简单工厂模式 VS 工厂方法模式）

wool王

前言
工大有许多同学是做java的，大家都知道java最大的优点是它的完全OO化和它在多年的发展过程中吸收和总结了许多先进的框架与模式，其中工厂模式就是最常用的模式之一。下面我想将我在学习和实践过程中对工厂模式的认识与了解介绍给大家。由于笔者能力限制，在实践中也没参与过什么大的项目，笔者参与过的项目用到的工厂模式主要是简单工厂模式（Simple Factory）和工厂方法模式（Factory Method），所以笔者在本文主要介绍的是这两种模式。



准备知识
在OO设计领域，我们知道前人总结了不少的经验，许多的经验在现代软件工程过程中已经被认为是原则来遵守。下面笔者摘抄几项下文涉及到的OO原则的定义。

OCP（开闭原则，Open-Closed Principle）：一个软件的实体应当对扩展开放，对修改关闭。我的理解是，对于一个已有的软件，如果需要扩展，应当在不需修改已有代码的基础上进行。

DIP（依赖倒转原则，Dependence Inversion Principle）：要针对接口编程，不要针对实现编程。我的理解是，对于不同层次的编程，高层次暴露给低层次的应当只是接口，而不是它的具体类。

LoD（迪米特法则，Law of Demeter）：只与你直接的朋友通信，而避免和陌生人通信。众所周知类（或模块）之间的通信越少，耦合度就越低，从而更有利于我们对软件的宏观管理。老子论“圣人之治”有相同的思想，《老子》云：“是以圣人之治，虚其心，实其腹，弱其志，常使民无知无欲。”，又云：“小国寡民，邻国相望，鸡犬之声相闻，民至老死，不相往来。”。佩服我们的老祖宗，N千年前就想到了西方N千年后才想到的东西，同时也佩服《java与模式》的作者阎宏，可以用中国传统哲学思想这么生动的说明这一软件设计原则。



简单工厂模式及实例
简单工厂模式又叫静态工厂模式，顾名思义，它是用来实例化目标类的静态类。下面我主要通过一个简单的实例说明简单工厂及其优点。

比如有个国家的运动员协会，他们是负责登记与注册职业运动员的（就好像我们国家的体育总局，呵呵，无论足球篮球还是乒乓球的运动员都必须在这里注册才能拿到我们国家职业运动员牌照）。一家体育俱乐部（比如篮球的广东宏远，足球的深圳健力宝）想获得球员为自己俱乐部效力，就必须通过这个运动员协会。

根据DIP我们可以设计一个“运动员”接口，“足球运动员”和“篮球运动员”（还有其他运动员）都实现“运动员”这个接口。而“运动员协会”就是一个简单工厂类，它负责实例化“运动员”。我们这里的“俱乐部”就是一个客户端（Client），不同的“俱乐部”就是不同的客户端。具体如下图表示：

[center]
[/center]

对于不同的俱乐部对象（无论是八一还是深圳健力宝），他们都是面向“运动员”接口编程，而不用管是“足球运动员”还是“篮球运动员”，也就是说实现了“运动员”接口的具体类“足球运动员”无需暴露给客户端。这也满足了DIP。但具体的俱乐部（比如足球的深圳健力宝）如何确保自己获取的是自己想要的运动员（健力宝俱乐部需要的当然是足球运动员）呢？这就需要“运动员协会”这一工厂类了。俱乐部通过调用“运动员协会”的具体方法，返回不同的实例。这同时也满足了LoD，也就是“深圳健力宝足球俱乐部”对象不直接与“足球运动员：李毅”对象通信，而是通过他们共同的“朋友”——“国家体育总局”通信。

下面给出各个类的程序，会有助于读者更好的了解笔者之前的介绍。

1. 
   
2. 运动员.java
   
3. public interface 运动员 {       
   
4.         public void 跑();
   
5.         public void 跳();
   
6. }
   
7. 
   
8. 足球运动员.java
   
9. public class 足球运动员 implements 运动员 {
   
10. 
    
11.         public void 跑(){
    
12.                 //跑啊跑
    
13.         }
    
14.        
    
15.         public void 跳(){
    
16.                 //跳啊跳
    
17.         }
    
18. }
    
19. 
    
20. 篮球运动员.java
    
21. public class 篮球运动员 implements 运动员 {
    
22. 
    
23.         public void 跑(){
    
24.                 //do nothing
    
25.         }
    
26.        
    
27.         public void 跳(){
    
28.                 //do nothing
    
29.         }
    
30. }
    
31. 
    
32. 体育协会.java
    
33. public class 体育协会 {
    
34.        
    
35.         public static 运动员 注册足球运动员(){
    
36.                 return new 足球运动员();
    
37.         }
    
38.        
    
39.         public static 运动员 注册篮球运动员(){
    
40.                 return new 篮球运动员();
    
41.         }
    
42. 
    
43. }
    
44. 
    
45. 俱乐部.java
    
46. public class 俱乐部 {
    
47.         private 运动员 守门员;
    
48.         private 运动员 后卫;
    
49.         private 运动员 前锋;
    
50. 
    
51.         public void test() {
    
52.                 this.前锋 = 体育协会.注册足球运动员();
    
53.                 this.后卫 = 体育协会.注册足球运动员();
    
54.                 this.守门员 = 体育协会.注册足球运动员();
    
55.                
    
56.                 守门员.跑();
    
57.                 后卫.跳();
    
58.         }
    
59. }
    

复制代码

以上就是简单工厂模式的一个简单实例，读者应该想象不用接口不用工厂而把具体类暴露给客户端的那种混乱情形吧（就好像没了体育总局，各个俱乐部在市场上自己胡乱的寻找仔细需要的运动员），简单工厂就解决了这种混乱。

我们用OCP看看简单工厂，会发现如果要对系统进行扩展的话治需要增加实现产品接口的产品类（上例表现为“足球运动员”，“篮球运动员”类，比如要增加个“乒乓球运动员”类），而无需对原有的产品类进行修改。这咋一看好像满足OCP，但是实际上还是需要修改代码的——对，就是修改工厂类。上例中如果增加“乒乓球运动员”产品类，就必须相应的修改“体育协会”工厂类，增加个“注册乒乓球运动员”方法。所以可以看出，简单工厂模式是不满足OCP的。



工厂方法模式及其实例
谈了简单工厂模式，下面继续谈谈工厂方法模式。前一节的最末点明了简单工厂模式最大的缺点——不完全满足OCP。为了解决这一缺点，设计师们提出了工厂方法模式。工厂方法模式和简单工厂模式最大的不同在于，简单工厂模式只有一个（对于一个项目或者一个独立模块而言）工厂类，而工厂方法模式有一组实现了相同接口的工厂类。下面我们通过修改上一节的实例来介绍工厂方法模式。

我们在不改变产品类（“足球运动员”类和“篮球运动员”类）的情况下，修改下工厂类的结构，如下图所示：

[center]
[/center]

相关代码如下：

1. 
   
2. 运动员.java
   
3. public interface 运动员 {       
   
4.         public void 跑();
   
5.         public void 跳();
   
6. }
   
7. 
   
8. 足球运动员.java
   
9. public class 足球运动员 implements 运动员 {
   
10. 
    
11.         public void 跑(){
    
12.                 //跑啊跑
    
13.         }
    
14.        
    
15.         public void 跳(){
    
16.                 //跳啊跳
    
17.         }
    
18. }
    
19. 
    
20. 篮球运动员.java
    
21. public class 篮球运动员 implements 运动员 {
    
22. 
    
23.         public void 跑(){
    
24.                 //do nothing
    
25.         }
    
26.        
    
27.         public void 跳(){
    
28.                 //do nothing
    
29.         }
    
30. }
    
31. 
    
32. 体育协会.java
    
33. public interface 体育协会 {
    
34.         public 运动员 注册();
    
35. }
    
36. 
    
37. 足球协会.java
    
38. public class 足球协会 implements 体育协会 {
    
39.         public 运动员 注册(){
    
40.                 return new 足球运动员();
    
41.         }
    
42. }
    
43. 
    
44. 篮球协会.java
    
45. public class 篮球协会 implements 体育协会 {
    
46.         public 运动员 注册(){
    
47.                 return new 篮球运动员();
    
48.         }
    
49. }
    
50. 
    
51. 俱乐部.java
    
52. public class 俱乐部 {
    
53.         private 运动员 守门员;
    
54.         private 运动员 后卫;
    
55.         private 运动员 前锋;
    
56. 
    
57.         public void test() {
    
58.                 体育协会 中国足协 = new 足球协会();
    
59.                
    
60.                 this.前锋 = 中国足协.注册();
    
61.                 this.后卫 = 中国足协.注册();
    
62. 
    
63.                 守门员.跑();
    
64.                 后卫.跳();
    
65.         }
    
66. }
    

复制代码

很明显可以看到，“体育协会”工厂类变成了“体育协会”接口，而实现此接口的分别是“足球协会”“篮球协会”等等具体的工厂类。

这样做有什么好处呢？很明显，这样做就完全OCP了。如果需要再加入（或扩展）产品类（比如加多个“乒乓球运动员”）的话就不再需要修改工厂类了，而只需相应的再添加一个实现了工厂接口（“体育协会”接口）的具体工厂类。



简单工厂模式与工厂方法模式大PK
从以上对两种模式的介绍可以了解到，工厂方法模式是为了克服简单工厂模式的缺点（主要是为了满足OCP）而设计出来的。但是，工厂方法模式就一定比简单工厂模式好呢？笔者的答案是不一定。下面笔者将详细比较两种模式。

1. 结构复杂度
从这个角度比较，显然简单工厂模式要占优。简单工厂模式只需一个工厂类，而工厂方法模式的工厂类随着产品类个数增加而增加，这无疑会使类的个数越来越多，从而增加了结构的复杂程度。

2.代码复杂度
代码复杂度和结构复杂度是一对矛盾，既然简单工厂模式在结构方面相对简洁，那么它在代码方面肯定是比工厂方法模式复杂的了。简单工厂模式的工厂类随着产品类的增加需要增加很多方法（或代码），而工厂方法模式每个具体工厂类只完成单一任务，代码简洁。

3.客户端编程难度
工厂方法模式虽然在工厂类结构中引入了接口从而满足了OCP，但是在客户端编码中需要对工厂类进行实例化。而简单工厂模式的工厂类是个静态类，在客户端无需实例化，这无疑是个吸引人的优点。

4.管理上的难度
这是个关键的问题。
我们先谈扩展。众所周知，工厂方法模式完全满足OCP，即它有非常良好的扩展性。那是否就说明了简单工厂模式就没有扩展性呢？答案是否定的。简单工厂模式同样具备良好的扩展性——扩展的时候仅需要修改少量的代码（修改工厂类的代码）就可以满足扩展性的要求了。尽管这没有完全满足OCP，但笔者认为不需要太拘泥于设计理论，要知道，sun提供的java官方工具包中也有想到多没有满足OCP的例子啊（java.util.Calendar这个抽象类就不满足OCP，具体原因大家可以分析下）。
然后我们从维护性的角度分析下。假如某个具体产品类需要进行一定的修改，很可能需要修改对应的工厂类。当同时需要修改多个产品类的时候，对工厂类的修改会变得相当麻烦（对号入座已经是个问题了）。反而简单工厂没有这些麻烦，当多个产品类需要修改是，简单工厂模式仍然仅仅需要修改唯一的工厂类（无论怎样都能改到满足要求吧？大不了把这个类重写）。

由以上的分析，笔者认为简单工厂模式更好用更方便些。当然这只是笔者的个人看法而已，毕竟公认的，工厂方法模式比简单工厂模式更“先进”。但有时过于先进的东西未必适合自己，这个见仁见智吧。


写在最后
本文仅讨论了两个常见的工厂模式，笔者很主观的分析了各自的优缺点，这必定会引起许多异议。如果对笔者观点有意见的，很欢迎跟贴批评指出。

其实究竟哪种模式更好，可能你会回答“都不好”，呵呵，别忘了，我们还有更“先进”的“抽象工厂模式”。。。

最后交代下版权信息。本文许多定义性的内容引用自《java与模式》（电子工业出版社，阎宏），这是本好书，有时间有机会希望大家可以好好看看，我在此书中是获益良多。另外笔者在写本文过程中还参考了《UML基础、案例与应用》（人民邮电出版社，Joseph Schmuller著，李虎、赵龙刚译），除此外其余内容均为原创，转贴请注明“工大后院版权所有”。


（以上均为个人观点，不代表工大后院立场。由于本文观点错误导致的各种损失本人与工大后院概不负责。）



（完）

[ Last edited by wool王 on 2005-10-18 at 18:48 ]

wool王

欢迎大家跟贴发表意见。

BS也好赞同也好，只要和本文内容和软件技术有关的话题，本人都乐意听取。

[ Last edited by wool王 on 2005-10-18 at 18:51 ]

jackvenn

wool,

good job.
等待更精彩的内容....

jerryjill

jerryjill [退出登录]
作者: wool王
评分: 积分 4 点
标题: [原创]工厂模式我之见（简单工厂模式 VS 工厂方法模式）

wool王

写了整晚。好累。顶一下。

斑竹，申精啊！

用程序诠释生命

刮目相看啊！
不过说了这两个工厂模式后怎么能不说抽象工厂模式呢？
这两个模式大多数人都能在不知不觉中应用了。
期待你的抽象工厂模式。

wool王

楼上的，这些模式虽然在java领域非常流行，但在.net和其他领域也算比较普及的。对你来说我相信还是有价值的。

抽象工厂我有时间会写下，怕写出来没读者而已。。。唉。。。

hjack

用户名:         hjack [退出登录]
作者:         wool王
评分:         积分 15 点
标题:         [原创]工厂模式我之见（简单工厂模式 VS 工厂方法模式）


wool,做得好

wool王

感谢斑竹的加分和加精。

更希望可以吸引OO设计方面有兴趣的同学参与讨论。

大鱼

我佩服楼主的毅力。
文章实在太长了。还是支持下了。

wool王

得到楼上的支持我很高兴。。。

有机会多交流。

aa_for_short

强啊

sasadong

Originally posted by aa_for_short at 2005-10-25 23:34:
强啊

我也简单说说我的理解和看法，我对这两个模式没有深刻的看法和体会，也没有去分析他们的优缺点，但在我的应用却也用过类似的模式。

模式，顾名思义就是在特定条件下的问题求解有一个已被公认为有效的解决方案。因而应用模式的前提应该是：你了解这个模式是为了解决（也擅长解决）什么问题？当前你是否遇到这样的问题？

所以，像楼主那样分析模式入骨的方法我认为不是好的方法。模式，应该从它应用条件以及解决问题两方面着手学习。

再谈谈我对工厂模式的理解，楼主举了个例子，我也用我的视角举例：
工厂模式：顾名思义，应用于类似工厂生产这样的需要有计划而相对封闭的产品生产情况。
应用条件：当客户需要一件产品，你需要按照计划的供给这个产品，而且这个产品的生产过程是保密的。那么你就有了应用工厂模式的最佳条件，显然，你可以设立一个制造符合客户需要的产品进行交付。

在这里，客户类似于楼主的“俱乐部”，产品类似于“运动员”，“工厂”类似于“体育协会”。但楼主的举例欠妥。工厂模式中的产品应该是一致符合客户需要的，但楼主所举例中，很显然，俱乐部是挑运动员的。

一个更为妥当的例子是：
客户，是一个宿舍里装了电话的工大学生。
产品，adsl上网线路。
工厂，电信。

当学生需要一个adsl宽带时，只管去电信营业厅填写宽带受理单，然后就能获得一条adsl宽带。

在这里，宽带这个产品是品质一致的，任何一条都能上网从而满足您的要求。但获得adsl线路可能是需要排队的，电信局的人要查看宿舍电话附近是否有空闲的端口，如果没有，可能需要扩容后才能给你，尽管可能需要多天，这是工厂生产的计划、策略。

另外一个例子是数据库连接池也符合这样的模式：
客户：数据库查询
产品：通向数据库的连接
工厂：数据库连接池管理对象


说了这么多，当然并不是否定楼主的看法，实际上大家是从两个视觉去探讨这个设计模式，楼主是从技术层面，而我是从应用层面。
当然，我的观点肯定是：模式的应用范围才是最重要的。只有会用、正确的用好模式，模式的好处和意义才真正体现出来。

我是2004届计机的，QQ：2116831
欢迎大家一起进步。

wool王

Originally posted by sasadong at 2005/10/26 17:33:




我也简单说说我的理解和看法，我对这两个模式没有深刻的看法和体会，也没有去分析他们的优缺点，但在我的应用却也用过类似的模式。

模式，顾名思义就是在特定条件下的问题求解有一个已被公认为有效的解 ...

师兄好.我是06届的,你的师弟.

我不知道师兄是否看清楚我的文章,,,不过我可真看不太明白师兄想表达什么...师兄回帖的时候可以继续指点指点...

关于这里:
在这里，客户类似于楼主的“俱乐部”，产品类似于“运动员”，“工厂”类似于“体育协会”。但楼主的举例欠妥。工厂模式中的产品应该是一致符合客户需要的，但楼主所举例中，很显然，俱乐部是挑运动员的。

我不明白师兄表达什么...俱乐部是挑运动员?俱乐部按照自己的需求调用不同的工厂获取实现相同接口的运动员...请注意这里:运动员就是运动员,他是一个接口,,,无论足球运动员还是篮球运动员...从具体类来说,,,俱乐部是挑运动员的没错,,,不过运动员的类型对俱乐部来说是隐蔽的,,,俱乐部只需挑选对了体育协会就会获取自己需要的运动员...

我表达能力也不好,,,师兄看明白我的意思没有?

wool王

Originally posted by sasadong at 2005/10/26 17:33:




我也简单说说我的理解和看法，我对这两个模式没有深刻的看法和体会，也没有去分析他们的优缺点，但在我的应用却也用过类似的模式。

模式，顾名思义就是在特定条件下的问题求解有一个已被公认为有效的解 ...

还有:
一个更为妥当的例子是：
客户，是一个宿舍里装了电话的工大学生。
产品，adsl上网线路。
工厂，电信。

这里我按我的理解说一说...这里"大学生"就相当于我的例子里的"俱乐部",,,"电信"相当于我例子里面的"中国足协",,,"adsl上网线路"相当于我例子中的"足球运动员",,,另外师兄的例子中不明显的是接口,,,我理解的接口是"电话线端口",相当于我例子中的"运动员"...

"大学生"想要获得"adsl上网线路",只需要去"中国电信"申请,然后"中国电信"就会提供"adsl上网线路",而"大学生"并不关心"adsl上网线路"是什么样的,,,因为他们只需知道"电话线端口"是什么样的,应该如何操作就可以了....我这么理解没错吧?

我的实例不也这样么?"某中超俱乐部"想要获得"足球运动员",只要去"中国足协"申请,然后"中国足协"就会注册一名"足球运动员"给"俱乐部",而"某中超俱乐部"并不担心该运动员是否会踢球,因为他们从"足协"那里活动的"运动员"肯定是他们想要的"足球运动员"...

我估计师兄没看清我文章的表述...还有,如果师兄例子中假设有另一个客户端,,,就叫做"家里装了电话线的soho一族",,,想活动产品是"传真服务"的话,,,那例子是不是就跟我例子的"篮球运动员"那些对应了呢???或者师兄你还有更好的解释...

wool王

最后再说说...我和师兄一样,,,也是个注重应用的人,,,我也不喜欢什么东西都按照所谓理论的"按部就班"...

我以前做东西的时候这种想法根深蒂固,,,总觉得自己的方法有时比教条的方法跟方便好用...不过当我开始接触较为复杂的东西后,特别是需要考虑所谓维护性和扩展性的时候,你不得不承认那些业界权威和专家们提出来的东西真的是有用的...尽管感觉太"教条"化...

有机会的化,,,请师兄分享下你不用教条式的东西也能设计出一个良性系统的经验...

sasadong

Originally posted by wool王 at 2005-10-27 02:39:


还有:
一个更为妥当的例子是：
客户，是一个宿舍里装了电话的工大学生。
产品，adsl上网线路。
工厂，电信。

这里我按我的理解说一说...这里"大学生"就相当于我的例子里 ...

呵呵，你好。
指点不敢，我的理解能力也是有限：
我只是看到当我把代码改成
俱乐部.java
public class 俱乐部 {
        private 运动员 守门员;
        private 运动员 后卫;
        private 运动员 前锋;

        public void test() {
                this.前锋 = 体育协会.注册篮球运动员();
                this.后卫 = 体育协会.注册篮球运动员();
                this.守门员 = 体育协会.注册篮球运动员();
               
                守门员.跑();
                后卫.跳();
        }
}

时，或者
俱乐部.java
public class 俱乐部 {
        private 运动员 守门员;
        private 运动员 后卫;
        private 运动员 前锋;

        public void test() {
                体育协会 中国足协 = new 篮球协会();
               
                this.前锋 = 中国足协.注册();
                this.后卫 = 中国足协.注册();

                守门员.跑();
                后卫.跳();
        }
}

结果程序运行正确，我看到一堆易建联、朱芳雨等活蹦乱跳的高个在顶头球而已。所以就斗胆说你举的例子不妥当。

实际上，你说的篮球协会、足球协会是体育协会的具体类的问题，有一个很好的例子可以说明。
好像是.net的吧？xml parser的使用就是一个所谓的工厂模式，在语言的范畴里，语言制订者不知道具体的xml parser会是哪个（xml parser可以由很多厂家有自己不同的实现，也就是还不知道具体类的名称）？但语言层面又迫切需要一个让用户得到xml parser的对象。于是一个根的xmlParserFactory就出来了，另外还有一个XmlParser的接口，声明xmlParserFactory的CreateXmlPaser方法返回的东西应该是这个接口的实现。然后系统装上了不同厂商实现的XmlParser，有微软自己的，有libxml的 c＋＋wapper的，有apache基金会的，有sun的，有ibm的，只要实现了XmlParser接口，并且安装正确使得xmlParserFactory的CreateXmlPaser方法能够找到并识别，于是，所需要的xmlParser就能通过“xml parser的名称”来获得，然后干活。

wool王

哦,,,这点让师兄误会了...

师兄你举的例子应该式"简单工厂模式"的...请看看我在简单工厂模式的例子...

至于这里我确实表达不好让人吾会了...我这里的"俱乐部"只是想说明是个客户端,,,所以只用了"俱乐部"几个字,,,如果我改成"足球俱乐部"师兄你觉得对吗???如果是"足球俱乐部"的话,他们很理所当然的懂得去找"足协",,,而不是"深圳健力宝"会找到"中国篮协"去要"朱芳雨"了...


就好像师兄例子中"大学生"懂得找(在师兄的例子里好像也只能找)"中国电信"装ADSL一样...只有一个工厂,这是简单工厂的特征...

我举的那个运动员的例子是为了说明"工厂方法模式"的...假设师兄例子中的"大学生"是"在北方某大学读书的大学生"(某些地方是网通的天下),,,他还能找"中国电信"吗???

我的例子一样的道理,,,"足球俱乐部"理所当然不会找到"中国篮协"...

[ Last edited by wool王 on 2005-10-26 at 19:16 ]

wool王

可能我的文章表述得不够清楚,,,对"简单工厂"和"工厂方法"的对比不是太明显,,,可能让师兄以为我只是在介绍"简单工厂"...

[ Last edited by wool王 on 2005-10-27 at 02:29 ]

sasadong

Originally posted by wool王 at 2005-10-27 02:39:


还有:
一个更为妥当的例子是：
客户，是一个宿舍里装了电话的工大学生。
产品，adsl上网线路。
工厂，电信。

这里我按我的理解说一说...这里"大学生"就相当于我的例子里 ...

我觉得你的想法是很全面的，看到了需求的变化并且事先就考虑设计对变化的支持。只是呢？你举的例子有问题而已，如果一定要表示工厂方法返回的对象的类别（接口）的话，那可以这样举例子
用校体育队伍代替俱乐部看看？
校队可是什么运动员都要的，只要运动员够厉害。
而体育协会相应的就成为“校体育部”了，注册方法也就相应改成“谈论确认”了。