程式碼無錯就是優？----簡單工廠模式
不識廬山真面目只緣身在此山中
山重水複疑無路，柳暗花明又一村
簡短的兩句詩大概就可以概括我此刻學習的心情了吧！
開始大話設計模式這本書的第一章，時間並不長，但對於自己的寫程式碼能力，真是得到了很深的認識，原來程式碼不是寫出來了就行的，對於程式碼的要求我還差很多-------大話第一章簡單工廠模式，用小例子一步一步由淺入深的告訴我程式碼中的一些學問，而這些就是我所欠缺的。
比如開篇的例子，寫一個簡單的計算機程式附加程式碼如下：
classProgram
{
static void Main(string[] args)
{
Console.Write("請輸入數字A:"); //命名不規範
string A = Console.ReadLine();
Console.Write("請輸入運算子號（+、-、*、/）");
string B = Console.ReadLine();
Console.Write("請輸入數字C：");
string C = Console.ReadLine();
string D = "";
if (B =="+") //程式繁瑣，這樣寫意味著每個條件都要判斷一下，才能執行，
D =Convert.ToString(Convert.ToDouble (A) + Convert.ToDouble(C));
if (B == "-")
D =Convert.ToString(Convert.ToDouble(A) - Convert.ToDouble(C));
if (B == "*")
D =Convert.ToString(Convert.ToDouble(A) * Convert.ToDouble(C));
if (B == "/")
D =Convert.ToString(Convert.ToDouble(A) / Convert.ToDouble(C)); //如果除數為0就會報錯，那該怎麼辦
Console.WriteLine("結果是：" + D);
}
}
注：
如果是我去寫我會這麼寫，但是這其中就有好多不規範的地方 例如命名不規範，程式繁瑣，等等！這都是初學者的毛病吧！程式碼寫好了，但是沒有考慮到他的擴充套件性靈活性，複用性等等，這樣的程式碼還真挺可怕！此刻我也明白了耦合的含義，一個好的程式就是要低耦合，這樣才容易維護和擴充套件吧！
第一章由淺入深的寫，看到最後才理解了點什麼是簡單工廠模式，以及這樣的好處！下面我就來一一的記錄一下！
簡單工廠模式
簡單工廠模式又稱為靜態工廠方法模式屬於類的建立型模式
而它的實質是由一個工廠類根據傳入的引數，動態決定應該建立哪一個產品類的例項。也就是生產你要建立的實體物件。簡單工廠模式實際上不屬於23個GOF模式,但他可以作為工廠方法模式的一個引導.
我個人對此的理解：我覺的這就像是生活中的我們想定做某件衣服，於是我們去商店描述了我們的需求，然後商店把我們的需求交給工廠進而做出我們需要的衣服，這裡面的商店就相當於我們的Clothes 類，我們的需求就是方法類，商家建立這樣一個需求方法 ，交給工廠，工廠就繼承商家提供的方法類去做就可以。也許你會認為就一件衣服有那麼麻煩嗎又商家又工廠的，假如說定衣服的多了，中間就會出現各種各樣的問題，例如衣服大小啦，顏色啦，等等，這種情況下簡單工廠模式就出來了，我們可以很方便的去處理哪方面出現了問題，各司其職。這也就符合了低耦合的原則了吧
在簡單工廠模式中的一些概念
工廠--------角色
簡單工廠模式的核心，它負責實現建立所有例項的內部邏輯。工廠類可以被外界直接呼叫，建立所需的產品物件。
抽象產品----------角色
簡單工廠模式所建立的所有物件的父類，它負責描述所有例項所共有的公共介面。
具體產品---------角色
是簡單工廠模式的建立目標，所有建立的物件都是充當這個角色的某個具體類的例項。
利用簡單工廠模式的優點
工廠類是整個模式的關鍵.包含了必要的邏輯判斷,根據外界給定的資訊,決定究竟應該建立哪個具體類的物件.通過使用工廠類,外界可以從直接建立具體產品物件的尷尬局面擺脫出來,僅僅需要負責“消費”物件就可以了。而不必管這些物件究竟如何建立及如何組織的．明確了各自的職責和權利，有利於整個軟體體系結構的優化。
缺點
由於工廠類集中了所有例項的建立邏輯，違反了高內聚責任分配原則，將全部建立邏輯集中到了一個工廠類中；它所能建立的類只能是事先考慮到的，如果需要新增新的類，則就需要改變工廠類了。
當系統中的具體產品類不斷增多時候，可能會出現要求工廠類根據不同條件建立不同例項的需求．這種對條件的判斷和對具體產品型別的判斷交錯在一起，很難避免模組功能的蔓延，對系統的維護和擴充套件非常不利；
這些缺點在工廠方法模式中得到了一定的克服。
使用範圍
工廠類負責建立的物件比較少；
客戶只知道傳入工廠類的引數，對於如何建立物件（邏輯）不關心；
由於簡單工廠很容易違反高內聚責任分配原則，因此一般只在很簡單的情況下應用。
專門定義一個類來負責建立其他類的例項,被建立的例項通常都具有共同的父類.
static void main(string[] args) //主函式中簡單的呼叫
{
Operation oper;
oper =OperationFactory.createOperate("+");
oper.NumberA = 1;
oper.NumberB = 2;
double result = oper.GetResult();
Console.WriteLine(oper.GetResult());
}
}
public classOperation //主類中 獲取數字A.B 和 結果
{
private double _numberA=0;
private double _numberB = 0;
public double NumberA
{
get { return _numberA ;}
set { _numberA = value; }
}
public double NumberB
{
get { return _numberB; }
set { _numberB = value; }
}
public virtual double GetResult()
{
double result = 0;
return result;
}
}
classOperationAdd : Operation //加法
{
public override double GetResult()
{
double result = 0;
result= NumberA+NumberB ;
return result ;
}
}
classOperationSub : Operation //減法
{
public override double GetResult()
{
double result = 0;
result = NumberA - NumberB;
return result;
}
}
classOperationMul : Operation //乘法
{
public override double GetResult()
{
double result = 0;
result = NumberA * NumberB;
return result;
}
}
class OperationDiv:Operation //除法 繼承了主運算類
{
public override double GetResult()
{
double result = 0;
if(NumberB == 0) // 寫一個主類 也就是運算的數字和方法，然後再寫每個方法的時候去繼承重新寫這些方法就可以了
thrownew Exception("除數不能為0");
result = NumberA / NumberB;
return result;
}
}
public classOperationFactory ///建立了一個工廠，使用者已輸入符號，工廠就會判斷怎麼計算了
{
public static OperationcreateOperate(string operate)
{
Operation oper = null;
switch (operate)
{
case "+":
oper = new OperationAdd();
break;
case "-":
oper = new OperationSub();
break;
case "*":
oper = new OperationMul();
break;
case "/":
oper = new OperationDiv();
break;
}
return oper;
}
}
}
上面的程式碼例子就是一個簡單的工程模式例子，在我們沒有用簡單工廠模式之前，如果說我要增加演算法，那麼我就需要修改新增一個此運算方法的類和相應的方法。如果我們要修改其中的計算功能，那麼我們就要修改好多相關的選項，而此模式下，耦合性降低了，各司其職，想要新增演算法，新增一個類，和工廠中的一個分支即可，想要修改，也是相對對立的，這樣的程式碼才能利於維護的擴充套件，和開篇的那個程式碼比起來就更加完善了。
這就是簡單工廠模式的好處吧！隨著大話模式的繼續學習，後續還會總結另外23和設計模式交流學習！