同樣以計算器程式為參考物件,上一篇文章中通過業務的封裝將業務邏輯和介面邏輯分開

            從而降低了他們的耦合度,使得擴充套件性和維護性提高.但是僅僅這樣還不夠.因為,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;
	}
}
 

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;
    }
}

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;
    }
}
 

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;
	}
}

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 ;
	}
}

       時候就不會接觸到其他方法的程式碼。而且若有新的運算方式的時候，直接繼承在重

       寫，減少了出錯的可能，程式邏輯結構更加的清晰!

               不過問題也來了，實際運用中我們如何知道應該呼叫何種方法呢？也就是如何

       例項化物件的問題

              可以使用“簡單工廠模式”予以實現，用一個單獨的類來創造例項的過程，也就是

       工廠

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、抽象類的繼承類：

                              完成相應的邏輯功能

                           簡單工廠模式通過工廠類不必管物件如何建立和組織，有利於軟體結構的優化。

                           但是，工廠類中集中了所有例項的建立邏輯，違反了高內聚（類之間關係簡單）責任分配原則；他所能建立的類必須

                 是事先就可以考慮到的，如果新增新類，則必須修改工廠類了。如若產品類不斷增加，對系統的維護和擴充套件十分不利的！因

                 次該模式使用較少。

            ？思考：那如何解決簡單工廠模式所面臨的問題呢？

                      工廠方法模式！