<Java设计模式>—工厂方法模式
工厂方法模式是简单工厂模式的进一步抽象化和推广,工厂方法模式里不再只由一个工厂类决定那一个产品类应当被实例化,这个决定被交给抽象工厂的子类去做。
来看下它的组成:
1)抽象工厂角色: 这是工厂方法模式的核心,它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。
2)具体工厂角色:它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。
3)抽象产品角色:它是具体产品继承的父类或者是实现的接口。在java中一般有抽象类或者接口来实现。
4)具体产品角色:具体工厂角色所创建的对象就是此角色的实例。在java中由具体的类来实现。
工厂方法模式使用继承自抽象工厂角色的多个子类来代替简单工厂模式中的“上帝类”。正如上面所说,这样便分担了对象承受的压力;而且这样使得结构变得灵活 起来——当有新的产品(即暴发户的汽车)产生时,只要按照抽象产品角色、抽象工厂角色提供的合同来生成,那么就可以被客户使用,而不必去修改任何已有的代 码。可以看出工厂角色的结构也是符合开闭原则的!
下面来看下一个运算对象的简单工程的设计模式UML:
/**
* 加法工厂类(其他运算,请参照该类的写法)
*/
public class AddFactory implements IFactory{
@Override
public Operation getOperation() {
return new OperationAdd();
}
}
/**
*工厂模式的客户端写法
*/
public class FactoryClient {
public static void main(String[] args) {
IFactory factory = new AddFactory();
Operation operation = factory.getOperation();
operation.numberA = 11;
operation.numberB = 12;
double result = operation.getResult();
System.out.println("计算结果:"+result);
}
}
个人总结:工厂方法模式相对于简单工厂模式,大大提高了代码的拓展性,假如将来有了新的算法,那么只需要添加两个类(具体算法类,具体算法的工厂类),至于原来的算法类,就不需要进行修改了,当然这也就符合开闭原则(对拓展开放,对修改关闭),而简单工厂模式,需要添加一个具体算法类,然后去修改OperationFactory类的switch语句,对于这样的修改是不安全的,也不符合开闭原则。不过工厂方法模式缺点,第一个缺点:每每增加一个算法,那么就必须添加两个类,类的个数相对于之前多了两倍。第二个缺点:就是在客户端进行调用的时候,就必须创建指定算法的工厂类,那么客户端就多导入了一个具体工厂类的包,产生这样原因,也是工厂方法抽象导致的,它将客户端需要使用的工厂的判断交给了客户端,而简单工厂,通过switch语句,进行了判断,所以客户端就无需判断了。