在上一篇文章中,我记录了简单工厂的使用方法,上面的程序避免了很多的错误;但是这是比较好的方法吗,如果需要增加一个计算功能,那么除了需要增加一个实现类,还要在工厂方法中增加一个分支,那么这就违背了Open-Close-rules原则;要解决这个问题就是使用另外一个设计模式:工厂方法模式;
1、工厂方法模式其实和简单工厂模式差不多,在之所以叫工厂方法就是把简单工厂中的工厂类抽象出来了,成为一个接口,这个接口中有一个方法用于创建对象,其他类分别实现这个接口并实现里面的抽象方法,根据各个实现类的需要创建实例对象,具体代码如下:
增加抽象工厂接口:
public interface IFactory {
public Operation getOperation();
}
实现该抽象接口的类:
public class AddFactory implements IFactory {
@Override
public Operation getOperation() {
return new Add();
}
}
public class SubFactory implements IFactory {
@Override
public Operation getOperation() {
return new Sub();
}
}
public class MultipFactory implements IFactory {
@Override
public Operation getOperation() {
return new Multip();
}
}
public class DivisionFactory implements IFactory {
@Override
public Operation getOperation() {
return new Division();
}
}
//使用工厂方法,把判断调用哪一种操作的逻辑判断提取了出来
IFactory factory = new AddFactory();
Operation operation = factory.getOperation();
double result = operation.operate(1, 2);
System.out.println(result);
其实这样写只是把具体是哪一种计算的逻辑判断从工厂类中移到了主方法中;如果要增加一个功能,需要增加一个计算的实现类,还要增加一个抽象工厂的实现类,这看似比较麻烦,但是没有违背OCR原则;工厂方法其实就是定义了创建对象的抽象接口,然后让子类决定实例化哪一个类。
个人觉得没什么用处,似乎又回到了最初的地方,在简单工厂的基础之上再次封装,似乎是在循环。试想,IFactory factory = new AddFactory() 和Operation operation = new AddOperation()有啥区别呢,各位在实际使用中有答案的欢迎评论,谢谢!!!
简单工厂模式与工厂方法模式真正的避免了代码的改动了?没有。在简单工厂模式中,
新计算方法的加入要修改工厂角色中的判断语句;而在工厂方法模式中,要么将判断逻辑留在抽
象工厂角色中,要么在客户程序中将具体工厂角色写死(就象上面的例子一样)。而且产品
对象创建条件的改变必然会引起工厂角色的修改。
面对这种情况,Java 的反射机制与配置文件的巧妙结合突破了限制——这在 Spring 中
完美的体现了出来 --- 深入浅出设计模式