工厂模式—简单工厂模式(Simple Factory Pattern)

                        同样以计算器程序为参考对象,上一篇文章中通过业务的封装将业务逻辑和界面逻辑分开

            从而降低了他们的耦合度,使得扩展性和维护性提高.但是仅仅这样还不够.因为,Operation类中,加

            法、减法、乘法、除法的运算是在一起的,如若需要加入一种新的运算方式(开根)就势必去修

            原有的代码,不加注意就会造成问题.

                         因此,加减乘除运算有必要分离出来,降低各类运算之间的耦合度,这就要使用继承的方式

            来实现。首先需要一个运算的基类,之后再继承该基类(并且重写方法)

                        Operation类

package com.kiritor;
/**
 * 运算基类*/
public class Operation {
    private double num1 = 0.0;
    private double num2 = 0.0;
	public double getNum1() {
		return num1;
	}
	public void setNum1(double num1) {
		this.num1 = num1;
	}
	public double getNum2() {
		return num2;
	}
	public void setNum2(double num2) {
		this.num2 = num2;
	}
    
	public double getResult(double numA ,double numB) throws Throwable
	{
		double result =0.0;
		return result;
	}
}
                     OperationAdd类

package com.kiritor;
/**
 * 加法运算*/
public class OperationAdd extends Operation{
    @Override
    public double getResult(double numA, double numB) {
    	double result = 0.0;
    	result = numA+numB;
    	return result;
    }
}
              OperationSub类

package com.kiritor;
/**
 * 减法类*/
public class OperationSub extends Operation{
    @Override
    public double getResult(double numA, double numB) {
    	double result = 0.0;
    	result = numA-numB;
    	return result;
    }
}
             OperationMul类

package com.kiritor;
/**
 * 乘法类*/
public class OperationMul extends Operation{
 
	@Override
	public double getResult(double numA, double numB) {
		double result = 0.0;
		result = numA * numB;
		return result;
	}
}
                  OperationDiv类
package com.kiritor;
/**
 * 除法类*/
public class OperationDiv extends Operation{
 
	 @Override
	public double getResult(double numA, double numB) throws Throwable {
		double result = 0.0;
		if(numB==0)
			throw new Exception("除数不能为零!");
		result = numA / numB ;
		return result ;
	}
}
             这里通过继承与方法的重写使得各方法分开了,因此在修改某个方法的代码的

       时候就不会接触到其他方法的代码。而且若有新的运算方式的时候,直接继承在重

       写,减少了出错的可能,程序逻辑结构更加的清晰!


               不过问题也来了,实际运用中我们如何知道应该调用何种方法呢?也就是如何

       实例化对象的问题

              可以使用“简单工厂模式”予以实现,用一个单独的类来创造实例的过程,也就是

       工厂

               OperationFactory类:
package com.kiritor;
/**
 * 生产运算类的工厂*/
public class OperationFactory {
   public static Operation bulidOperation(String opr)
   {
	   Operation operation = null;
	   switch (opr) {
	case "+":
		operation = new OperationAdd();
		break;
	case "-":
		operation = new OperationSub();
		break;
	case "*":
		operation = new OperationMul();
		break;
	case "/":
		operation = new OperationDiv();
		break;
	}
	   return operation;
   }
}
                 主类:

Operation operation =null;
		operation = OperationFactory.bulidOperation("+");
		try {
			System.out.println(operation.getResult(1.2, 2.1));
		} catch (Throwable e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
             经过上述的变换,若果需要添加一个开根运算, 只需要实现一个运算子类,之后再修改工厂 就可以了

          大大降低了程序的耦合度!

      

         类图结构为:

     

                           从设计模式的类型上来说,简单工厂模式属于创建型模型(关于设计模式的具体分类在下一篇博文中会归纳),

               也称其为静态工厂方法模式,但是不属于23中GOF设计模式之一,简单工厂模式采用工厂对象决定创建类的实例。实质上

               就是有一个工厂类根据传入的参数,动态决定应该创建类(该类必须继承父类或者接口)的实例。

                       简单工厂模式包含的角色;

                1、工厂类:

                              该模式的核心,实现创建所有实例,该类可以直接被外界调用,创建对象。

                 2、抽象类:

                              工厂所能创建的所有对象的父类,是所有实例的公共接口

                 3、抽象类的继承类:

                              完成相应的逻辑功能

                           简单工厂模式通过工厂类不必管对象如何创建和组织,有利于软件结构的优化。

                           但是,工厂类中集中了所有实例的创建逻辑,违反了高内聚(类之间关系简单)责任分配原则;他所能创建的类必须

                 是事先就可以考虑到的,如果添加新类,则必须修改工厂类了。如若产品类不断增加,对系统的维护和扩展十分不利的!因

                 次该模式使用较少。

            ?思考:那如何解决简单工厂模式所面临的问题呢?

                      工厂方法模式!








评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值