模式概念
这是我在读的《图解设计模式》一书上的一张图,最能体现工厂方法模式的效果与内涵。
在Factory Method模式中,父类决定实例的生成方式,但并不决定所要生成的具体的类,具体的处理全部交给子类负责。这样就可以生成实例的框架和实际负责生成实例的类结构。
书中案例
书上的是一个生产id卡的例子,主要用于生产每个人的ID卡。一共有5个类:
AbstractProduct类和AbstractFactory类属于framework包,提供实例生成的框架。
IDCard类和IDCardFactory类是负责实际生产的类,他们在idcard的包下。
Main类是客户端类。
但是就我个人而言,看的确实有点头昏,下面这个例子是我认为比较好理解的。
具体代码
定义抽象产品接口
public interface Product {
}
定义具体产品类
public class ConcreteProductA implements Product {
public ConcreteProductA(){
System.out.println("create A ...");
}
}
public class ConcreteProductB implements Product {
public ConcreteProductB(){
System.out.println("create B ...");
}
}
定义抽象工厂
public abstract class Creator {
public abstract Product create();
}
定义具体工厂
public class ConcreteCreatorA extends Creator{
@Override
public Product create() {
return new ConcreteProductA();
}
}
public class ConcreteCreatorB extends Creator{
@Override
public Product create() {
return new ConcreteProductB();
}
}
调用方法
public static void main(String[] args) {
Creator creator = new ConcreteCreatorA();
creator.create();
creator = new ConcreteCreatorB();
creator.create();
}
输出
create A ...
create B ...
看到这边,尤其是上面那个思维导图的时候是特别的懵,还是不太懂这个设计模式的理念。
原理图
这一张图中作为父类的框架中的Creator与Product与具体加工中的ConcreteCreator与ConcreteProduct是平行的,只能单向箭头干涉。
组成角色
- Creator(创建者):
Creator角色属于框架这一方,它是负责生成Product角色的抽象类,但具体的处理则由子类 ConcreteCreator角色决定。Creator角色对于实际负责生成实例的ConcretCreator角色一无所知,它唯一知道的就是,只要调用Product角色和生成实例的方法,就可以生成Product的实例。 - Product(产品):
Product角色属于框架这一方,是一个抽象类。定义了在Factory Method模式中生成的那些实例所持有的接口,但具体的处理则由子类ConcreteProduct角色决定。 - ConcreteProduct(具体的产品):
ConcreteProduct角色属于具体加工这一方,它决定了具体的产品内容。 - ConcreteCreator(具体的创建者):
ConcreteCreator角色属于具体加工这一方,它负责生成具体的产品ConcreteProduct。
优点
采用这种设计模式,可以避开对象创建中的产生的冲突问题,把对象创建的过程包装起来,提高了代码的适用性和灵活度。
总结
每种设计模式都是互通的,学习工厂方法模式之前可以先参考一下TemplateMethod模式,是有些许相似的。