簡單工廠模式：提高程式碼可維護性與擴充套件性的設計模式

哈嘍！今天開始，慢慢和大家一起分享我學習和理解設計模式的歷程。

前言

設計模式（Design Pattern）是前輩們對程式碼開發經驗的總結，是解決特定問題的一系列套路。它不是語法規定，而是一套用來提高程式碼可複用性、可維護性、可讀性、穩健性以及安全性的解決方案。

1995 年，GoF（Gang of Four，四人組/四人幫）合作出版了《設計模式：可複用物件導向軟體的基礎》一書，共收錄了 23 種設計模式，從此樹立了軟體設計模式領域的里程碑，人稱「GoF設計模式」。

讓我們從建立型模式開始。先來說說工廠模式！

基本介紹

工廠模式是一種建立型的物件導向設計模式，目的將建立物件的具體過程包裝起來，從而達到更高的靈活性。工廠模式的本質就是用工廠方法代替 new 操作建立一種範例化物件的方式，以提供一種方便地建立有同種型別介面的產品的複雜物件。

簡單說來：我們不new物件了，讓工廠方法來生產物件

工廠模式可以細分如下三類：

簡單工廠模式（Simple Factory）

工廠方法模式（Factory Method）

抽象工廠模式（Abstract Factory）

今天來看下工廠模式之簡單工廠模式

簡單工廠模式

簡單工廠模式（Simple Factory）又叫做靜態工廠方法（Static Factory Method）模式，但不屬於 23 種 GOF 設計模式之一。

簡單工廠模式的實質是由一個工廠類根據傳入的引數，動態決定應該建立哪一個產品類（這些產品類繼承自一個父類別或介面）的範例。

從上面的描述中，我們可以抽象出這麼幾個角色：

工廠類：負責建立需要的範例
產品抽象類：工廠類能建立出來的所有產品類的抽象。它負責描述所有範例所共有的公共介面。（這裡必須要一個抽象類，不然不能保證返回的不同的產品類屬於同一個型別）
產品類：工廠類建立出來的目標。它（們）是產品抽象類的具體實現。

範例

產品抽象類：

public interface Phone {
  public String info();
}

產品類（具體實現類）：

public class HuaweiPhone implements Phone{
  @Override
  public String info() {
    return "我是手機華為";
  }
}

public class ApplePhone implements Phone{
  @Override
  public String info() {
    return "我是蘋果手機";
  }
}

工廠類

public class PhoneFactory{
  public static Phone createPhone(String name){
    Phone p = null;
    switch(type) {
      case "huawei":
        p = new HuaweiPhone();
        break;
      case "apple":
        p = new ApplePhone();
        break;
      default:
        throw new UnsupportedOperationException("不支援該操作");
    }
    return p;
  }
}

讓我們來測試下：

public class Test {
  public static void main(String[] args) {
    SimpleFactory PhoneFactory = new PhoneFactory();
 
    Phone phone1 = PhoneFactory.createPhone("huawei");
    System.out.println(phone1.info());
    Phone phone2 = PhoneFactory.createPhone("apple");
    System.out.println(phone2.info());
  }
}

輸出：

我是華為手機

我是蘋果手機

給什麼條件，就建立什麼型別的範例，就這麼簡單。不愧簡單工廠模式的名號。

簡單工廠模式存在的問題

上面的例子中，我們是知道該工廠能建立華為手機和蘋果手機。所有我們在測試的時候，也只建立了這兩個範例。

如果現在要建立一個」小米手機「，那這個工廠就沒法建立出來了

小夥伴可能會說，那就在switch...case...中再增加一個case "xiaomi"吧！

嗯嗯，這個辦法能解決」小米手機「的建立問題。但如果後面我們還要陸續建立」oppo手機「」三星手機「...

如果延續這種方法，我們每增加一種手機的建立，就要新增一次case，也就要每次都修改 PhoneFactory 類。這顯然是違背了【開閉原則】。同時，這樣的工廠類太被動了。

那怎麼解決這個問題呢？我們下期再分享。

簡單工廠模式總結

工廠類是整個簡單工廠模式的關鍵。包含了必要的邏輯判斷，根據外界給定的資訊，決定究竟應該建立哪個具體類的物件。

通過使用工廠類，外界可以從直接建立具體產品物件的尷尬局面擺脫出來（不用直接new物件了），僅僅需要負責「消費」物件就可以了。而不必管這些物件究竟如何建立及如何組織的。明確了各自的職責和權利，有利於整個軟體體系結構的優化。

但是由於工廠類集中了所有範例的建立邏輯，違反了高內聚責任分配原則，將全部建立邏輯集中到了一個工廠類中；它所能建立的類只能是事先考慮到的，如果需要新增新的類，則就需要改變工廠類了。

當系統中的具體產品類不斷增多時候，可能會出現要求工廠類根據不同條件建立不同範例的需求．這種對條件的判斷和對具體產品型別的判斷交錯在一起，很難避免模組功能的蔓延，對系統的維護和擴充套件非常不利；

一句話：雖然簡單工廠模式實現了物件的建立和物件的使用分離，但增加新的具體產品需要修改工廠類的判斷邏輯程式碼，違背開閉原則。

為了解決這些缺點，就有了工廠方法模式。

我下回再講工廠方法，今天先到這裡了！