工廠模式作為很常見的設計模式，在日常工作中出鏡率非常高，程序員們一定要掌握它的用法喲，今天跟着老胡一起來看看吧。
舉個例子
現在先讓我們來看一個例子吧，比如，要開發一個簡單的計算器，完成加減功能，通過命令行讀入形如1+1的公式，輸出2這個結果，讓我們看看怎麼實現吧。
第一個版本
這個版本裏面，我們不考慮使用模式，就按照最簡單的結構，怎麼方便怎麼來。
思路非常簡單，僅需要實現以下幾個方法
class Program
{
static int GetOperatorIndex(string input)
{
int operatorIndex = 0;
for (; operatorIndex < input.Length; operatorIndex++)
{
if (!char.IsDigit(input[operatorIndex]))
break;
}
return operatorIndex;
}
static int GetOp(string input, int startIndex, int size = -1)
{
string subStr;
if (size == -1)
{
subStr = input.Substring(startIndex);
}
else
{
subStr = input.Substring(startIndex, size);
}
return int.Parse(subStr);
}
static int CalculateExpression(string input)
{
var operatorIndex = GetOperatorIndex(input); //得到運算符索引
var op1 = GetOp(input, 0, operatorIndex); //得到運算數1
var op2 = GetOp(input, operatorIndex + 1); //得到運算數2
switch (input[operatorIndex])
{
case '+':
return op1 + op2;
case '-':
return op1 - op2;
default:
throw new Exception("not support");
}
}
static void Main(string[] args)
{
string input = Console.ReadLine();
while(!string.IsNullOrEmpty(input))
{
var result = CalculateExpression(input);
Console.WriteLine("={0}", result);
input = Console.ReadLine();
}
}
}
代碼非常簡單，毋庸置疑，這個運算器是可以正常工作的。這也可能是我們大部分人剛剛踏上工作崗位的時候可能會寫出的代碼。但它有着以下這些缺點：
- 缺乏起碼的抽象，至少加和減應該能抽象出操作類。
- 缺乏抽象造成了巨型客戶端，所有的邏輯都嵌套在了客戶端裏面。
- 使用switch case缺乏擴展性，同時switch case也暗指了這部分代碼是屬於變化可能性比較高的地方，我們應該把它們封裝起來。而且不能把他們放在和客戶端代碼一起
接下來，我們引入我們的主題，工廠方法模式。
工廠方法模式版本
工廠方法模式使用一個虛擬的工廠來完成產品構建（在這裡是運算符的構建，因為運算符是我們這個程序中最具有變化的部分），通過把可變化的部分封裝在工廠類中以達到隔離變化的目的。我們看看UML圖：
依葫蘆畫瓢，我們設計思路如下：
- 設計一個IOperator接口，對應抽象的Product
- 設計AddOperator和SubtractOperator，對應具體Product
- 設計IOperatorFactory接口生產Operator
- 設計OperatorFactory實現抽象IFactory
關鍵代碼如下，其他讀取操作數之類的代碼就不在贅述。
interface IOperator
{
int Calculate(int op1, int p2);
}
class AddOperator : IOperator
{
public int Calculate(int op1, int op2)
{
return op1 + op2;
}
}
class SubtractOperator : IOperator
{
public int Calculate(int op1, int op2)
{
return op1 - op2;
}
}
interface IOperatorFactory
{
IOperator CreateOperator(char c);
}
class OperatorFactory : IOperatorFactory
{
public IOperator CreateOperator(char c)
{
switch(c)
{
case '+':
return new AddOperator();
case '-':
return new SubtractOperator();
default:
throw new Exception("Not support");
}
}
}
- 在CalculateExpression裏面使用他們
static IOperator GetOperator(string input, int operatorIndex)
{
IOperatorFactory f = new OperatorFactory();
return f.CreateOperator(input[operatorIndex]);
}
static int CalculateExpression(string input)
{
var operatorIndex = GetOperatorIndex(input);
var op1 = GetOp(input, 0, operatorIndex);
var op2 = GetOp(input, operatorIndex + 1);
IOperator op = GetOperator(input, operatorIndex);
return op.Calculate(op1, op2);
}
這樣，我們就用工廠方法重新寫了一次計算器，現在看看，好處有
- 容易變化的創建部分被工廠封裝了起來，工廠和客戶端以接口的形式依賴，工廠內部邏輯可以隨時變化而不用擔心影響客戶端代碼
- 工厂部分可以放在另外一個程序集，項目規劃會更加合理
- 客戶端僅僅需要知道工廠和抽象的產品類，不需要再知道每一個具體的產品（不需要知道如何構建每一個具體運算符），符合迪米特法則
- 擴展性增強，如果之後需要添加乘法multiple，那麼僅需要添加一個Operator類代表Multiple並且修改Facotry裏面的生成Operator邏輯就可以了，不會影響到客戶端
自此，我們已經在代碼裏面實現了工廠方法模式，但可能有朋友就會想，雖然現在擴展性增強了，但是新添加運算符還是需要修改已有的工廠，這不是違反了開閉原則么。。有沒有更好的辦法呢？當然是有的。
反射版本
想想工廠方法那個版本，我們為什麼增加新的運算符就會不可避免的修改現有工廠？原因就是我們通過switch case來硬編碼“教導”工廠如何根據用戶輸入產生正確的運算符，那麼如果有一種方法可以讓工廠自動學會發現新的運算符，那麼我們的目的不就達到了？
嗯，我想聰明的朋友們已經知道了，用屬性嘛，在C#中，這種方法完成類的自描述，是最好不過了的。
我們的設計思路如下：
- 定義一個描述屬性以識別運算符
- 在運算符中添加該描述屬性
- 在工廠啟動的時候，掃描程序集以註冊所有運算符
代碼如下：
class OperatorDescriptionAttribute : Attribute
{
public char Symbol { get; }
public OperatorDescriptionAttribute(char c)
{
Symbol = c;
}
}
[OperatorDescription('+')]
class AddOperator : IOperator
{
public int Calculate(int op1, int op2)
{
return op1 + op2;
}
}
[OperatorDescription('-')]
class SubtractOperator : IOperator
{
public int Calculate(int op1, int op2)
{
return op1 - op2;
}
}
class OperatorFactory : IOperatorFactory
{
private Dictionary<char, IOperator> dict = new Dictionary<char, IOperator>();
public OperatorFactory()
{
Assembly assembly = Assembly.GetExecutingAssembly();
foreach (var type in assembly.GetTypes())
{
if (typeof(IOperator).IsAssignableFrom (type)
&& !type.IsInterface)
{
var attribute = type.GetCustomAttribute<OperatorDescriptionAttribute>();
if(attribute != null)
{
dict[attribute.Symbol] = Activator.CreateInstance(type) as IOperator;
}
}
}
}
public IOperator CreateOperator(char c)
{
if(!dict.ContainsKey(c))
{
throw new Exception("Not support");
}
return dict[c];
}
}
經過這種改造，現在程序對擴展性支持已經很友好了，需要添加Multiple，只需要添加一個Multiple類就可以，其他代碼都不用修改，這樣就完美符合開閉原則了。
[OperatorDescription('*')]
class MultipleOperator : IOperator
{
public int Calculate(int op1, int op2)
{
return op1 * op2;
}
}
這就是我們怎麼一步步從最原始的代碼走過來，一點點重構讓代碼實現工廠方法模式，最終再完美支持開閉原則的過程，希望能幫助到大家。
其實關於最後那個通過標記屬性實現擴展，微軟有個MEF框架支持的很好，原理跟這個有點相似，有機會我們再聊聊MEF。
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※帶您來了解什麼是 USB CONNECTOR ?
※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面
※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!
※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化
※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
※教你寫出一流的銷售文案?
※聚甘新
![[經驗棧]C#監測IPv4v6網速及流量](https://www.3chy2.com.tw/wp-content/uploads/2020/10/6a50eb7ae66b99f1fed7d7f14fc6a6d5.jpg)
