設計模式-簡單工廠模式
簡單工廠模式
簡單工廠模式可以理解為有一個工廠類別。該工廠類別會根據調用者的輸入回傳給調用者相對應的類別實體。
範例（沒有使用簡單工廠模式）
class Program
{
static void Main()
{
var benz = new Benz();
benz.StartEngine();
var bmw = new BMW();
bmw.StartEngine();
}
}
public class BMW
{
public void StartEngine()
{
Console.WriteLine("BMW starting engine...");
}
}
public class Benz
{
public void StartEngine()
{
Console.WriteLine("BENZ starting engine...");
}
}
沒使用簡單工廠模式有可能會遇到的問題
-
在程式碼裡面需要用到汽車物件的地方都需要實例化一個汽車物件。想像一下實例化的程式碼在應用程式到處都是，那當有新需求需要修改汽車類別時，例如汽車類別名字的修改，那會需要改動很多地方。
-
在某些情況，汽車物件在實例化需要的一些內部訊息需要被封裝不讓調用者知道時，使用簡單工廠模式可以幫我們做到。
範例（使用簡單工廠模式）
class Program
{
static void Main(string[] args)
{
ICar bmw = CarFactory.GetCar(Brand.BMW);
bmw.StartEngine();
ICar benz = CarFactory.GetCar(Brand.BENZ);
benz.StartEngine();
}
}
public interface ICar
{
void StartEngine();
}
public static class CarFactory
{
public static ICar GetCar(Brand brand)
{
switch (brand)
{
case Brand.BENZ:
return new Benz();
case Brand.BMW:
return new Bmw();
default:
return new Benz();
}
}
}
public enum Brand
{
BMW,
BENZ,
}
public class Bmw : ICar
{
public void StartEngine()
{
Console.WriteLine("BMW starting engine...");
}
}
public class Benz : ICar
{
public void StartEngine()
{
Console.WriteLine("BENZ starting engine...");
}
}
用了簡單工廠模式解決的問題
-
實例化汽車類別時的修改，例如所有的汽車類別建構子必須傳入 int price當作汽車的販賣價格。我們不用在應用程式的程式碼海裡面找每一個實例化汽車類別的地方，需要在CarFactory裡面做修改就好（當然所有汽車類別也要多加一個接受int 的建構子）。
-
良好地封裝了實例化的過程，調用者對於實例化的過程完全不知情。
-
調用者與汽車物件的關係建立在抽象介面上，減低了與具體汽車物件的耦合。
簡單工廠模式的不足
-
每次有新的汽車品牌，我們必須修改CarFactory的GetCar方法，增加一個switch case，這就違反了SOLID 原則中的開放/封閉原則(OCP)。