簡單工廠模式

簡單工廠模式會定義一個工廠類，會根據不同的引數返回不同類的例項（一般利用多型返回父類），但這些類都有一個共同的父類。

現在想一個例子：如果我們要實現一個簡單的計數器（+,-,*,/）應該怎麼做？

第一種方法：就是把所有的方法揉在一起，根據傳入的運算子進行相應計算

switch (operator)
{
  case '+':
     result=a+b;
  case '-':
     result=a-b;
  ......

}

很明顯，這樣的程式不易擴充套件和維護！當我們需要修改某些操作或新增運算時，需要修改整個程式碼！

第二種方法：就是有一個抽象父類Operator類它有抽象的方法getResult()，具體的計運算元類:OperatorAdd,OperatorSub,OperatorMul,OperatorDiv，子類只需要重寫getResult()方法即可

現在思考一個問題：我們如何例項化具體的計算物件呢？

這就是簡單工廠模式！

public class OperationFactory{
   public static Operation createOperate(String operate){
     Operator op;
     switch(operate){
       case "+":
         op=new OperatorAdd();
         break;
       case "-":
         op=new OperatorSub();
         break;
       case "*":
         op=new OperatorMul();
         break;
       case "/":
         op=new OperatorDiv();
         break;
       

      }

   return op;

}
}
 

我們為什麼要返回父類？

這其實是利用了多型的思想，是我們在客戶端利用時不必侷限於具體的子類，而複用同樣的程式碼

Operator op;
op=OperationFactory.createOperate("+");
op.NumberA=1;
op.NumberB=2;
int result=op.getResult();

當我們需要修改某個運算操作時，只需要修改相應的子類！

當我們需要新增運算操作時，只需要新增子類，同時在工廠類中新增switch分支！

利弊

優點

• 工廠類含有必要的判斷邏輯，可以決定在什麼時候建立哪一個產品類的例項，客戶端可以免除直接建立產品物件的責任，而僅僅“消費”產品；簡單工廠模式通過這種做法實現了對責任的分割，它提供了專門的工廠類用於建立物件。

• 客戶端無須知道所建立的具體產品類的類名，只需要知道具體產品類所對應的引數即可，對於一些複雜的類名，通過簡單工廠模式可以減少使用者的記憶量。

• 通過引入配置檔案，可以在不修改任何客戶端程式碼的情況下更換和增加新的具體產品類，在一定程度上提高了系統的靈活性。

缺點

• 由於工廠類集中了所有產品建立邏輯，一旦不能正常工作，整個系統都要受到影響。

• 使用簡單工廠模式將會增加系統中類的個數，在一定程式上增加了系統的複雜度和理解難度。

• 系統擴充套件困難，一旦新增新產品就不得不修改工廠邏輯，同樣破壞了“開閉原則”；在產品型別較多時，有可能造成工廠邏輯過於複雜，不利於系統的擴充套件和維護。

• 簡單工廠模式由於使用了靜態工廠方法，造成工廠角色無法形成基於繼承的等級結構。

適用環境

在以下情況下可以使用簡單工廠模式：

• 工廠類負責建立的物件比較少：由於建立的物件較少，不會造成工廠方法中的業務邏輯太過複雜。

• 客戶端只知道傳入工廠類的引數，對於如何建立物件不關心：客戶端既不需要關心建立細節，甚至連類名都不需要記住，只需要知道型別所對應的引數。