【设计模式】Factory模式

假设你的软件中用到了Oracle数据库，你自己实现了一个类Oracle，于是你在程序中直接创建了一个Oracle的实例，如下，

Oracledb=newOracle();

后来你发现很多中小型客户不愿意花钱购买Oracle，于是你考虑用 甚至文件来替换Oracle。于是你不得不修改你的应用程序并重新编译。

DB db=new DB();

or

FlatFileDB db=newFlatFileDB();

这时你的软件中可以支持三种类型的数据库：FlatFile， 与Oracle。可以考虑为这三种数据库创建统一的接口Data ，如下图所示：

于是再次修改代码如下：

Data db=newOracle();

or

Data db=new DB();

or

Data db=newFlatFileDB();

由于你的软件对数据库的操作都是通过接口Data 进行的，并且决不会调用特定于任何数据库（FlatFileDB, DB或Oracle）的方法，那么你的软件就不应该依赖于具体的数据库类。为了彻底摆脱对具体数据库类的依赖，可以采用Factory模式，通过Factory实例来创建具体数据库的实例，而不是在客户程序中直接new了。如下图所示：

Data FactoryImpl的代码如下：

publicclassData FactoryImplimplementsData Factory

{

publicData create(Stringdata Type)throwsException

{

if(data Type.equals("FlatFileDB"))

returnnewFlatFileDB();

elseif(data Type.equals(" DB"))

returnnew DB();

elseif(data Type.equals("Oracle"))

returnnewOracle();

else

thrownewException("Unsupported data Type "+data Type);

}

}

你可以将对数据库的选择放在配置文件中，以后可以自如的在这三种数据库中动态切换，而不用重新编译应用程序。

其实Factory模式也体现了以前讲过的依赖倒置原则（DIP），应用程序应该依赖于抽象，而不是具体类。应用Factory模式，应用程序只依赖于抽象的接口就能创造出具体的对象实例。

Factory模式在单元测试中也大有用途。在上面例子中，在开发过程中，通常希望在不使用数据库的情况下单独测试Application，这时就可以实现一个MockData Factory以及相应的MockData 。具体就不多说了。

Factory模式是一个很有效的模式，但是使用Factory模式也会带来复杂性，至少增加了额外的几个类，所以不应该盲目使用此模式，无论创建任何对象都使用Factory模式的想法未免过于极端了。