首先对造人过程进行分析,该过程涉及三个对象:女娲、八卦炉、三种不同肤色的人
Client
表示女娲造人类图
所有人种定义完毕,下一步就是定义一个八卦炉,然后烧制人类
最可能给八卦炉下达什么样的生产命令呢?
应该是给我生产出一个黄色人种(YellowHuman类)
而不会是给我生产一个会走、会跑、会说话、皮肤是黄色的人种
因为这样的命令增加了交流的成本,作为一个生产的管理者,只要知道生产什么就可以了,而不需要事物的具体信息
在这里采用了泛型,通过定义泛型对createHuman的输入参数产生两层限制
● 必须是Class类型
● 必须是Human的实现类
其中的T
表示,只要实现了Human接口的类都可以作为参数
只有一个八卦炉,其实现生产人类的方法
人种有了,八卦炉也有了,剩下的工作就是女娲采集黄土,然后命令八卦炉开始生产
人种有了,八卦炉有了,负责生产的女娲也有了 运行一下,结果如下所示
以上就是工厂方法模式
工厂方法模式的通用类图 在工厂方法模式中,抽象产品类Product负责定义产品的共性,实现对事物最抽象的定义;Creator为抽象创建类,也就是抽象工厂,具体如何创建产品类是由具体的实现工厂ConcreteCreator完成的。工厂方法模式的变种较多,我们来看一个比较实用的通用源码。
具体的产品类可以有多个,都继承于抽象产品类
该通用代码是一个比较实用、易扩展的框架,读者可以根据实际项目需要进行扩展
一个产品对象具体由哪一个产品生成是由工厂类决定的
在数据库开发中,大家应该能够深刻体会到工厂方法模式的好处:如果使用JDBC连接数据库,数据库从MySQL切换到Oracle,需要改动的地方就是切换一下驱动名称(前提条件是SQL语句是标准语句),其他的都不需要修改,这是工厂方法模式灵活性的一个直接案例。在所有需要生成对象的地方都可以使用,但是需要慎重地考虑是否要增加一个工厂类进行管理,增加代码的复杂度
万物皆对象,那万物也就皆产品类
例如需要设计一个连接邮件服务器的框架,有三种网络协议可供选择:POP3、IMAP、HTTP
我们就可以把这三种连接方法作为产品类,定义一个接口如IConnectMail
然后定义对邮件的操作方法
用不同的方法实现三个具体的产品类(也就是连接方式)
再定义一个工厂方法,按照不同的传入条件,选择不同的连接方式
如此设计,可以做到完美的扩展,如某些邮件服务器提供了WebService接口,很好,我们只要增加一个产品类就可以了
例如通过WebService与一个非Java的项目交互,虽然WebService号称是可以做到异构系统的同构化,但是在实际的开发中,还是会碰到很多问题,如类型问题、WSDL文件的支持问题,等等。从WSDL中产生的对象都认为是一个产品,然后由一个具体的工厂类进行管理,减少与外围系统的耦合。
例如,测试一个类A,就需要把与类A有关联关系的类B也同时产生出来,我们可以使用工厂方法模式把类B虚拟出来,避免类A与类B的耦合。目前由于JMock和EasyMock的诞生,该使用场景已经弱化了,读者可以在遇到此种情况时直接考虑使用JMock或EasyMock
工厂方法模式有很多扩展,而且与其他模式结合使用威力更大,下面将介绍4种扩展。
我们这样考虑一个问题:一个模块仅需要一个工厂类,没有必要把它产生出来,使用静态的方法就可以了,根据这一要求,我们把上例中的AbstarctHumanFactory
修改一下
简单工厂模式类图
我们在类图中去掉了AbstractHumanFactory
抽象类,同时把createHuman
方法设置为静态类型,简化了类的创建过程,变更的源码仅仅是HumanFactory和NvWa类
待考证
HumanFactory类仅有两个地方发生变化
createHuman
前增加static关键字工厂类发生变化,也同时引起了调用者NvWa的变化
简单工厂模式中的场景类
运行结果没有发生变化,但是我们的类图变简单了,而且调用者也比较简单,该模式是工厂方法模式的弱化,因为简单,所以称为简单工厂模式
(Simple Factory Pattern),也叫做静态工厂模式
在实际项目中,采用该方法的案例还是比较多的
当我们在做一个比较复杂的项目时,经常会遇到初始化一个对象很耗费精力的情况,所有的产品类都放到一个工厂方法中进行初始化会使代码结构不清晰 例如,一个产品类有5个具体实现,每个实现类的初始化(不仅仅是new,初始化包括new一个对象,并对对象设置一定的初始值)方法都不相同,如果写在一个工厂方法中,势必会导致该方法巨大无比,那该怎么办?
考虑到需要结构清晰,我们就为每个产品定义一个创造者,然后由调用者自己去选择与哪个工厂方法关联 我们还是以女娲造人为例,每个人种都有一个固定的八卦炉,分别造出黑色人种、白色人种、黄色人种
多个工厂类的类图
多工厂模式的抽象工厂类 抽象方法中已经不再需要传递相关参数了,因为每一个具体的工厂都已经非常明确自己的职责:创建自己负责的产品类对象。
三个具体的创建工厂都非常简单,但是,如果一个系统比较复杂时工厂类也会相应地变复杂。
运行结果还是相同 每一个产品类都对应了一个创建类,好处就是创建类的职责清晰,而且结构简单,但是给可扩展性和可维护性带来了一定的影响。为什么这么说呢?如果要扩展一个产品类,就需要建立一个相应的工厂类,这样就增加了扩展的难度。因为工厂类和产品类的数量相同,维护时需要考虑两个对象之间的关系。
当然,在复杂的应用中一般采用多工厂的方法,然后再增加一个协调类,避免调用者与各个子工厂交流,协调类的作用是封装子工厂类,对高层模块提供统一的访问接口。
单例模式的核心要求就是在内存中只有一个对象
,通过工厂方法模式也可以只在内存中生产一个对象
工厂方法模式替代单例模式类图
Singleton定义了一个private的无参构造函数,目的是不允许通过new的方式创建一个对象
单例类
Singleton保证不能通过正常的渠道建立一个对象
负责生成单例的工厂类 通过获得类构造器,然后设置private访问权限,生成一个对象,然后提供外部访问,保证内存中的对象唯一
以上通过工厂方法模式创建了一个单例对象,该框架可以继续扩展,在一个项目中可以产生一个单例构造器,所有需要产生单例的类都遵循一定的规则(构造方法是private),然后通过扩展该框架,只要输入一个类型就可以获得唯一的一个实例。
何为延迟初始化(Lazy initialization)?一个对象被消费完毕后,并不立刻释放,工厂类保持其初始状态,等待再次被使用。延迟初始化是工厂方法模式的一个扩展应用,其通用类图如图8-6所示。
image
图8-6 延迟初始化的通用类图
ProductFactory负责产品类对象的创建工作,并且通过prMap变量产生一个缓存,对需要再次被重用的对象保留,Product和ConcreteProduct是一个示例代码,请参考代码清单8-8和代码清单8-9。ProductFactory如代码清单8-22所示。
代码清单8-22 延迟加载的工厂类
public class ProductFactory { private static final Map<String,Product> prMap = new HashMap(); public static synchronized Product createProduct(String type) throws Exception{ Product product =null; //如果Map中已经有这个对象 if(prMap.containsKey(type)){ product = prMap.get(type); }else{ if(type.equals("Product1")){ product = new ConcreteProduct1(); }else{ product = new ConcreteProduct2(); } //同时把对象放到缓存容器中 prMap.put(type,product); } return product; } }
代码还比较简单,通过定义一个Map容器,容纳所有产生的对象,如果在Map容器中已经有的对象,则直接取出返回;如果没有,则根据需要的类型产生一个对象并放入到Map容器中,以方便下次调用。
延迟加载框架是可以扩展的,例如限制某一个产品类的最大实例化数量,可以通过判断Map中已有的对象数量来实现,这样的处理是非常有意义的,例如JDBC连接数据库,都会要求设置一个MaxConnections最大连接数量,该数量就是内存中最大实例化的数量。
延迟加载还可以用在对象初始化比较复杂的情况下,例如硬件访问,涉及多方面的交互,则可以通过延迟加载降低对象的产生和销毁带来的复杂性。