在在Java中应用设计模式中应用设计模式-FactoryMethod
在设计模式中,Factory Method也是比较简单的一个,但应用非常广
泛,EJB,RMI,COM,CORBA,Swing中都可以看到此模式的影子,它是最重要的模式之一.在很多地
方我们都会看到xxxFactory这样命名的类,那么,什么是Factory Method,为什么要用这个模式,如何
用Java语言来实现该模式,这就是本文想要带给大家的内容.
基本概念
Factory Method是一种创建性模式,它定义了一个创建对象的接口,但是却让子类来决定具体实例
化哪一个类.当一个类无法预料要创建哪种类的对象或是一个类需要由子类来指定创建的对象时
我们就需要用到Factory Method 模式了.简单说来,Factory Method可以根据不同的条件产生不同
的实例,当然这些不同的实例通常是属于相同的类型,具有共同的父类.Factory Method把创建这些
实例的具体过程封装起来了,简化了客户端的应用,也改善了程序的扩展性,使得将来可以做最小的
改动就可以加入新的待创建的类. 通常我们将Factory Method作为一种标准的创建对象的方法,当
发现需要更多的灵活性的时候,就开始考虑向其它创建型模式转化
简单分析
图1是Factory Method 模式的结构图,这里提供了一些术语,让我们可以进行更方便的描述:
1. Product: 需要创建的产品的抽象类.
2. ConcreteProduct: Product的子类,一系列具体的产品.
3. Creator: 抽象创建器接口,声明返回Product类型对象的Factory Method.
4. ConcreteCreator: 具体的创建器,重写Creator中的Factory Method,返回ConcreteProduct类
型的实例.
图1: Factory Method 模式结构
由此可以清楚的看出这样的平行对应关系: Product <====> Creator ; ConreteProduct <====>
ConreteCreator
抽象产品对应抽象创建器,具体产品对应具体创建器.这样做的好处是什么呢?为什么我们不直接
用具体的产品和具体的创建器完成需求呢?实际上我们也可以这样做.但通过Factory Method模式
来完成,客户(client)只需引用抽象的Product和Creater,对具体的ConcreteProduct和
ConcreteCreator可以毫不关心,这样做我们可以获得额外的好处:
首先客户端可以统一从抽象创建器获取产生的实例,Creator的作用将client和产品创建过程
分离开来,客户不用操心返回的是那一个具体的产品,也不用关心这些产品是如何创建的.同
时,ConcreteProduct也被隐藏在Product后面,ConreteProduct继承了Product的所有属性,并
实现了Product中定义的抽象方法,按照Java中的对象造型(cast)原则,通过ConcreteCreator
产生的ConcreteProduct可以自动的上溯造型成Product.这样一来,实质内容不同的
ConcreteProduct就可以在形式上统一为Product,通过Creator提供给client来访问.
其次,当我们添加一个新的ConcreteCreator时,由于Creator所提供的接口不变,客户端程序不
会有丝毫的改动,不会带来动一发而牵全身的灾难, 这就是良好封装性的体现.但如果直接用
ConcreteProduct和ConcreteCreator两个类是无论如何也做不到这点的. 优良的面向对象设
计鼓励使用封装(encapsulation)和委托(delegation),而Factory Method模式就是使用了封装
和委托的典型例子,这里封装是通过抽象创建器Creator来体现的,而委托则是通过抽象创建
器把创建对象的责任完全交给具体创建器ConcreteCreator来体现的.
现在,请再回头看看基本概念中的那段话,开始也许觉得生涩难懂,现在是不是已经明朗化了很多.
下面让我们看看在 Java 中如何实现Factory Method模式,进一步加深对它的认识.
具体实施
先说明一点,用Factory Method模式创建对象并不一定会让我们的代码更短,实事上往往更长,我们
也使用了更多的类,真正的目的在于这样可以灵活的,有弹性的创建不确定的对象.而且,代码的可
重用性提高了,客户端的应用简化了,客户程序的代码会大大减少,变的更具可读性.
剩余8页未读，继续阅读
资源评论
