假设你的软件中用到了Oracle数据库,你自己实现了一个类Oracle,于是你在程序中直接创建了一个Oracle的实例,如下,
Oracledb=newOracle();
后来你发现很多中小型客户不愿意花钱购买Oracle,于是你考虑用XML甚至文件来替换Oracle。于是你不得不修改你的应用程序并重新编译。
XMLDB db=newXMLDB();
or
FlatFileDB db=newFlatFileDB();
这时你的软件中可以支持三种类型的数据库:FlatFile,XML与Oracle。可以考虑为这三种数据库创建统一的接口Database,如下图所示:
于是再次修改代码如下:
Databasedb=newOracle();
or
Databasedb=newXMLDB();
or
Database db=newFlatFileDB();
由于你的软件对数据库的操作都是通过接口Database进行的,并且决不会调用特定于任何数据库(FlatFileDB,XMLDB或Oracle)的方法,那么你的软件就不应该依赖于具体的数据库类。为了彻底摆脱对具体数据库类的依赖,可以采用Factory模式,通过Factory实例来创建具体数据库的实例,而不是在客户程序中直接new了。如下图所示:
DatabaseFactoryImpl的代码如下:
publicclassDatabaseFactoryImplimplementsDatabaseFactory
{
publicDatabasecreate(StringdatabaseType)throwsException
{
if(databaseType.equals("FlatFileDB"))
returnnewFlatFileDB();
elseif(databaseType.equals("XMLDB"))
returnnewXMLDB();
elseif(databaseType.equals("Oracle"))
returnnewOracle();
else
thrownewException("Unsupported databaseType "+databaseType);
}
}
你可以将对数据库的选择放在配置文件中,以后可以自如的在这三种数据库中动态切换,而不用重新编译应用程序。
其实Factory模式也体现了以前讲过的依赖倒置原则(DIP),应用程序应该依赖于抽象,而不是具体类。应用Factory模式,应用程序只依赖于抽象的接口就能创造出具体的对象实例。
Factory模式在单元测试中也大有用途。在上面例子中,在开发过程中,通常希望在不使用数据库的情况下单独测试Application,这时就可以实现一个MockDatabaseFactory以及相应的MockDatabase。具体就不多说了。
Factory模式是一个很有效的模式,但是使用Factory模式也会带来复杂性,至少增加了额外的几个类,所以不应该盲目使用此模式,无论创建任何对象都使用Factory模式的想法未免过于极端了。
领取专属 10元无门槛券
私享最新 技术干货