设计模式--抽象工厂之小解
古文新编（级别：初级）
I. 动 机
II. 虚拟案例
III. 针对中国企业为系统建模
IV. 针对美国企业为系统建模
V. 引入工厂类
VI. 可配置化(切换)的工厂类
VII. 符合开闭原则的可配置化工厂类
VIII. 抽象工厂类
IX. 总结
I. 动 机
设计模式相信大家早已不再陌生，尤其在Java语言被广泛使用以后 ，GoF设计模式更是被广大Java程序员所熟知。
抽象工厂模式作为GoF模式中最重要、最基本的一个 ，几乎无处不被使用。但是你真正地完全理解了抽象工厂设计模式了吗？要更好地理解它，不单要知道怎么去调用它，更重要的是如何写出一个抽象工厂框架。
看了许多抽象工厂设计模式的中文文档，总觉得阐述得还不够简单，文档格式的组织也不够良好，提供的代码不够完整，这都导致了读者要么没有耐心读完整篇文档，要么不能真正实践例子代码。
于是有了"新解"的想法（一厢情愿吧），即虚拟一个尽可能直观、简单的案例，尝试从一个更加通俗的角度去诠释它，并提供完整的可以运行的Eclipse工程去调试运行它，非常适合设计模式初学者。
II. 虚拟案例
为中国某企业开发的财务系统，系统涉及大量的财务运算。其中有一项为了员工每月净工资，其规则如下：
图1.
根据上面分析，ChineseSalary为Softo系统的业务规则类，公开caculate方法;query_chinese_salary.jsp调用业务规则类查询工资单，承担了客户端的角色。根据代码职责的不同进行人员分工：
1 Java Developer : 开发Java业务规则类（工资计算）
1 Jsps Developer: 编写前端页面进行工资查询
代码清单：
ChineseSalary.java
运行query_chinese_salary.jsp结果如下：
Your salary is 3520.0 RMB
IV. 针对美国企业为系统建模
1.问题提出
为了拓展国际市场,MaxDO要把该系统移植给美国公司使用。美国企业的月净工资和中国有所不同，计算公式如下：
图2
代码清单
1. AmericanSalary
运行query_american_salary.jsp结果如下：
Your salary is $3850.0
V. 引入工厂模式
1.问题提出
到目前为止，且不谈代码的结构和质量，我们可以说：系统的工资计算模块已经构建好了。让我们再次回顾一下该系统的发展历程：
起初，我们只考虑将Softo系统运行于中国企业。但随着MaxDO公司业务向海外拓展， MaxDO需要将该系统移植给美国使用。为了之个移植时,MaxDO为美国企业新建业务规则类AmericanSalary，然后通知JSP开发人员（有可能是合作公司哦）增加一个客户端jsp页面并告知新的业务规则的调用方法.
按照这种开发模式，试想一个规模问题：某天如果该系统移植到印度、日本、比利时..., 将会出现什么样的开发模式？
每移植到一个新的国家，业务规则便增加了一个，这个无可厚非，但是每一次你都不得不请求JSP人员增加调用页面；而在jsp开发人员看来，每一次的移植他做的工作都很重复很无聊：
图3
基于业务规则本身的共性，AmercianSalary,ChineseSalary能抽象出一个接口叫Salary. 但是Salary是不能实例化的，客户端JSP如何调用呢？为此我们定义了一个辅助类
Factory（很形象吧，Salary像是一个产品，Factory来生产它）提供一个静态方法为
图4
这个就是抽象工厂模式！
代码清单：业务规则类
IX. 总结
现实的应用将有许多Factory的变种，而且可能要求Factory模式更加安全、高效，所以需要多线程安全和单体模式考虑。以后有时间可以探讨。
另外可以去Eclipse插件站下载一个叫PatternBox的插件来辅助学习Design Pattern.
最终版的代码可以在附件中下载（AbstractFactory.zip）
蝈蝈龙 2009.02.07
