簡單工廠方法
但寫的程序卻不一定easy維護，不easy擴展，更不easy復用，為了把代碼寫的易維護、易擴展、易復用，我們非常有必要學習設計模式
1.緊耦合和松耦合
利用面向對象的性質，封裝、繼承、多態
2.單一職責原則：就一個類而言，應該僅有一個引起它變化的原因
3.簡單工廠方法
簡單工廠模式的實質是由一個工廠類依據傳入的參數。動態決定應該創建哪一個產品類（這些產品類繼承自一個父類或接口）的實例。
/// <summary>
/// 運算類
/// </summary>
public class Operation
{
private double _numberA = 0;
private double _numberB = 0;
/// <summary>
/// 數字A
/// </summary>
public double NumberA
{
get
{
return _numberA;
}
set
{
_numberA = value;
}
}
/// <summary>
/// 數字B
/// </summary>
public double NumberB
{
get
{
return _numberB;
}
set
{
_numberB = value;
}
}
/// <summary>
/// 得到運算結果
/// </summary>
/// <returns></returns>
public virtual double getResult()
{
double result = 0;
return result;
}
}
/// <summary>
/// 加法類
/// </summary>
class OperationAdd : Operation
{
public override double getResult()
{
double result = 0;
result = NumberA + NumberB;
return result;
}
}
/// <summary>
/// 減法類
/// </summary>
class OperationSub : Operation
{
public override double getResult()
{
double result = 0;
result = NumberA - NumberB;
return result;
}
}
/// <summary>
/// 運算類工廠
/// </summary>
class OperationFactory
{
public static Operation createOperate(string operate)
{
Operation oper = null;
switch (operate)
{
case "+":
{
oper = new OperationAdd();
break;
}
case "-":
{
oper = new OperationSub();
break;
}
}
return oper;
}
}
長處：
工廠類是整個模式的關鍵.包括了必要的邏輯推斷,依據外界給定的信息,決定到底應該創建哪個詳細類的對象.通過使用工廠類,
外界能夠從直接創建詳細產品對象的尷尬局面擺脫出來,只須要負責“消費”對象就能夠了。而不必管這些對象到底怎樣創建及怎樣組織的．
明白了各自的職責和權利，有利於整個軟件體系結構的優化。
缺點：
因為工廠類集中了所有實例的創建邏輯，違反了高內聚責任分配原則，將所有創建邏輯集中到了一個工廠類中；它所能創建的類僅僅能是事先考慮到的，
假設須要加入新的類，則就須要改變工廠類了。
當系統中的詳細產品類不斷增多時候，可能會出現要求工廠類依據不同條件創建不同實例的需求．
這樣的對條件的推斷和對詳細產品類型的推斷交錯在一起，非常難避免模塊功能的蔓延，對系統的維護和擴展非常不利。
這些缺點在工廠方法模式中得到了一定的克服。
使用場景：
工廠類負責創建的對象比較少；
客戶僅僅知道傳入工廠類的參數，對於怎樣創建對象（邏輯）不關心；
因為簡單工廠非常easy違反高內聚責任分配原則。因此一般僅僅在非常簡單的情況下應用。
簡單工廠方法