從一個計算器開始說起——C#中的工廠方法模式
阿新 • • 發佈：2020-06-19
工廠模式作為很常見的設計模式，在日常工作中出鏡率非常高，程式設計師們一定要掌握它的用法喲，今天跟著老胡一起來看看吧。
舉個例子
現在先讓我們來看一個例子吧，比如，要開發一個簡單的計算器，完成加減功能，通過命令列讀入形如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,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
關鍵程式碼如下，其他讀取運算元之類的程式碼就不在贅述。
- IOperator介面
interface IOperator
{
int Calculate(int op1,int p2);
}
- 具體Operator
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; } }
- Factory介面
interface IOperatorFactory
{
IOperator CreateOperator(char c);
}
- 具體Factory
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,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。