作为最常用的创建模式,Factory模式在这里起到连接接口和实现的桥梁作用。通过Factory模式,我们可以根据具体需要加载相应的实现,并将此
实现作为所对应接口的一个实例提供给业务层使用:


通过上面的代码我们可以看到,通过接口我们将具体的DAO实现类从码中分离。
也就是说,业务层通过接口调用底层实现,具体的DAO实现类不会出现在我们的业务代码中。而具体实现类在配置文件中加以配置,之后
DAOFactory.getDAO方法通过读取配置文件获得当前我们期望使用的实现类的类名,再通过Java Class动态加载机制加载后返回。
从而我们的代码并不依赖某个特定的实现类,只需要在部署的时候在配置文件中指定当前采用的实现类即可。
本例中,为了提高性能,避免每次调用都读取配置文件所引起的大量磁盘操作,采用HashMap作为DAO缓存实现示例:





























DAOConfig类实现了配置文件的读取功能,并根据配置文件中的内容加载指定的接口和实现类:









































一个示例配置文件如下:










DAOConfig中使用了JFig读取XML配置文件(dao.xml)。关于JFig的具体信息请参见Http://jfig.sourceforge.net
ClassToolKit.loadClass方法实现了类文件的动态加载:




















经过Factory模式的改造,我们的业务层代码也进行了相应的改造:















相对于改造前,这些代码里混杂了一些数据访问层的内容,如DAOFactory.getDAO方法的调用
Proxy模式的作用是通过提供一个中间层(Proxy),将上层调用接口与下层实现相衔接,先看Proxy模式改造的业务层代码












Bad Smell消失了,业务层也清洁了,而CustomerProxy和PromotionProxy做了些什么呢?























摘自《深入浅出Hibernate》