名詞理解：
工廠(Factory)模式我們可以做如下理解，假設有一個Audi的公司生產汽車（似乎也不用假設了），它掌握一項核心的技術就是生產汽車，另一方面，它生產的汽車是有不同型號的，並且在不同的生產線上進行組裝。當客戶通過銷售部門進行預定後，Audi公司將在指定的生產線上爲客戶生產出它所需要的汽車。
策略(Strategy)模式在結構上與工廠模式類似，唯一的區別是工廠模式實例化一個產品的操作是在服務端來做的，換句話說客戶端傳達給服務端的只是某種標識，服務端根據該標識實例化一個對象。而策略模式的客戶端傳達給服務端的是一個實例，服務端只是將該實例拿過去在服務端的環境裏執行該實例的方法。這就好比一個對汽車不甚瞭解的人去買車，他在那一比劃，說要什麼什麼樣的，銷售部門根據他的這個“比劃”來形成一份訂單，這就是工廠模式下的工作方式。而策略模式下那個顧客就是個行家，他自己給出了訂單的詳細信息，銷售部門只是轉了一下手就交給生產部門去做了。通過兩相對比，我們不難發現，採用工廠模式必須提供足夠靈活的銷售部門，如果用戶有了新的需求，銷售部門必須馬上意識到這樣纔可以做出合適的訂單。所以倘一款新車出來了，生產部門和銷售部門都需要更新，對顧客來說也需要更新對新車的描述所以需要改動的地方有三處。而策略模式中的銷售部門工作比較固定，它只負責接受訂單並執行特定的幾個操作。當一款新車出來時，只需要對服務端的生產部門和客戶端的代碼進行更新，而不需要更新銷售部門的代碼。
技術支持：
簡單工廠和策略的基礎都是因爲面向對象的封裝與多態。他們實現的思想都是先設定一個抽象的模型並從該模型派生出符合不同客戶需求的各種方法，並加以封裝。
模型：
Audi公司的產品有A6, A4, TT, R8...我們如果將每種車的生產做一個方法，那麼我們的模型結構應該是這樣的
namespace ConsoleApplication5
{
class Audi
{
public void CreateA4()
{
//Do someting
}
public void CreateA6()
{
//Do something
}
public void CreateTT()
{
//Do something
}
}
}
設想一下如果Audi出了一款新車，那麼我們必須要在Audi這個類裏邊添加新的方法，這就要求總公司提供對Audi這個類的修改權限，如果新車項目的負責人對其他車型的負責人有什麼意見，
它可以輕而易舉的改亂他們的代碼，讓他們的工作陷入癱瘓（當然現實中沒有人會這麼幹）。我們的目標是新生產線的項目負責人只有權限對自己的項目情況作出修改，除此之外他一無所知。
我們可以考慮如下的模型結構
namespace ConsoleApplication5
{
abstract class BaseFactory
{
public abstract void MakeCar();
}
class A6Factory : BaseFactory
{
public override void MakeCar()
{
Console.WriteLine("Auti A6 is created");
}
}
class A4Factory : BaseFactory
{
public override void MakeCar()
{
Console.WriteLine("Auti A4 is created");
}
}
class TTFactory : BaseFactory
{
public override void MakeCar()
{
Console.WriteLine("Auti TT is created");
}
}
class R8Factory : BaseFactory
{
public override void MakeCar()
{
Console.WriteLine("Auti R8 is created");
}
}
class SelectCarFactoryPattern
{
static BaseFactory bf = null;
public static void OrderCar(string strCarType)
{
switch (strCarType)
{
case "A6":
bf = new A6Factory();
bf.MakeCar();
break;
case "A4":
bf = new A4Factory();
bf.MakeCar();
break;
case "R8":
bf = new R8Factory();
bf.MakeCar();
break;
default:
Console.WriteLine("Error car");
break;
}
}
}
class SelectCarStrategyPattern
{
BaseFactory carFactory = null;
public SelectCarStrategyPattern(BaseFactory carFactory)
{
this.carFactory = carFactory;
}
public void OrderCar()
{
this.carFactory.MakeCar();
}
}
}這種結構的好處是將每一條生產線進行了封裝，在必要的情況下可以使他們的源代碼在彼此之間不可見，這一點正是我們所希望看到的。另外如果每條生產線涉及的代碼量很大，
這種結構也可以避免重複編譯，我們只需要對新增加的生產線進行編譯而之前的生產線我們甚至連動都不需要動。到目前爲止，簡單工廠模式和策略模式沒有什麼區別。
工廠模式和策略模式的區別在於實例化一個對象的位置不同，對工廠模式而言，實例化對象是放在服務端的，下面這個類就是用來做這個的。
class SelectCarFactoryPattern
{
static BaseFactory bf = null;
public static void OrderCar(string strCarType)
{
switch (strCarType)
{
case "A6":
bf = new A6Factory();
bf.MakeCar();
break;
case "A4":
bf = new A4Factory();
bf.MakeCar();
break;
case "R8":
bf = new R8Factory();
bf.MakeCar();
break;
default:
Console.WriteLine("Error car");
break;
}
}而策略模式實例化對象的操作在客戶端，服務端的“銷售部門”只負責傳遞該對象，並在服務端的環境裏執行特定的操作。正如下面這個類所做的
class SelectCarStrategyPattern
{
BaseFactory carFactory = null;
public SelectCarStrategyPattern(BaseFactory carFactory)
{
this.carFactory = carFactory;
}
public void OrderCar()
{
this.carFactory.MakeCar();
}
}足夠能區分使用哪種策略的參數，而這最好的就是該策略的實例了。
namespace ConsoleApplication5
{
class Customer
{
static void Main(string[] args)
{
//This part is the customer part code for simple factory pattern
Console.WriteLine("Please select your car from 'A6', 'A4', 'R8'");
string strTemp = Console.ReadLine();
SelectCarFactoryPattern.OrderCar(strTemp);
//This part is the customer part code for strategy pattern
SelectCarStrategyPattern scstrategy = new SelectCarStrategyPattern(new A4Factory());
scstrategy.OrderCar();
}
}
}