设计模式之-工厂方法模式

在上一篇文章中,我记录了简单工厂的使用方法,上面的程序避免了很多的错误;但是这是比较好的方法吗,如果需要增加一个计算功能,那么除了需要增加一个实现类,还要在工厂方法中增加一个分支,那么这就违背了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 中
完美的体现了出来 --- 深入浅出设计模式

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

心所向皆可成

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值