1.意圖
定義一個創建對象的接口，讓子類決定實例化那一個類，使接口類型能夠延遲到子類。
結構圖
現在我們考慮一個下班回家做飯的過程。假定我們要設計煮飯的類支持煮飯的類型有稀飯和軟飯兩種方式，我們先不談設計模式
public class cooking
{
public void CookingSort()
{
Console.Writeline("稀飯");
}
public void CookingHard()
{
Console.Writeline("軟飯");
}
public void DoType(string Type)
{
case "soft"
CookingSort();
break;
case "hard"
CookingHard();
break;
default:
break;
}
}
這種方式顯然不適合面向對象語言程序設計要求，如果我們要增加一種類型的那么我們就得改cooking類這就使得cooking變的不穩定；
分析以上的業務關系和事情結果和過程發現兩種煮飯的方式完全不同所有不應該有聯系，那么我們重這里分離出兩個對象來。
public class CookingSoft
{
public void cooking_soft()
{
Console.WriteLine("煮飯");
}
}
public class COOKINGHARD
{
public void cooking_hard()
{
Console.writeLine("硬飯");
}
}
對該設計進行進一步抽象
結構圖如下
public abstract class Cooking
{
public abstract void cook();
}
public class CookingSoft:Cooking
{
public voerrid void cook()
{
Console.writeline("稀飯");
}
}
public class CookingHard:Cooking
{
public voerrid void cook()
{
Console.writeline("硬飯");
}
}
現在我們在需要增加一種美味的大米飯需要做的事情是什么呢，只需在寫一個class然后繼承cooking類實現里面的方法不需要去改變原來已經寫好的類
這樣的設計很好的滿足啦單一原則
那么我們如何去調用這段程序呢
我們經常會這樣去寫
CookingHard ch = new CookingHard();
ch.cook();
當我們需要做另外一種飯的時候就得改變上面這段代碼這樣的工作量是可想而知的
此時就需要對應用和實例類型的解耦
這就引入工廠模式
public class softFactor
{
public CookingSoft Creat()
{
return new CookingSoft();
}
}
public class hadFactor
{
public CookingHard Creat()
{
return new CookingHard ();
}
}
這兩個工廠和具體的產品之間是平行的結構，並一一對應，並在它們的基礎上抽象出一個公用的接口，結構圖如下：
代碼如下
public abstract class cookFactor
{
public abstract Cooking Create();
}
public class softFactor:cookFactor
{
public overrid Cooking Create()
{
return new CookingSoft();
}
}
public class App
{
public static void Main(string[] args)
{
cookFactor factory = new softFactor();
Log log = factory.Create();
log.Create();
}
}
自此完成啦整個工廠模式的構建和代碼分析過程