跨架構平臺試圖解決這個問題，通過提供一個抽象層，將底層架構與應用程式分離開來，從而使得應用程式可以在多種不同的架構上運行。跨架構平臺通常包括以下三個組件 ...
哈嘍！今天開始，慢慢和大家一起分享我學習和理解設計模式的歷程。
前言
設計模式（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對象了），僅僅需要負責“消費”對象就可以了。而不必管這些對象究竟如何創建及如何組織的。明確了各自的職責和權利，有利於整個軟體體繫結構的優化。
但是由於工廠類集中了所有實例的創建邏輯，違反了高內聚責任分配原則，將全部創建邏輯集中到了一個工廠類中；它所能創建的類只能是事先考慮到的，如果需要添加新的類，則就需要改變工廠類了。
當系統中的具體產品類不斷增多時候，可能會出現要求工廠類根據不同條件創建不同實例的需求．這種對條件的判斷和對具體產品類型的判斷交錯在一起，很難避免模塊功能的蔓延，對系統的維護和擴展非常不利；
一句話：雖然簡單工廠模式實現了對象的創建和對象的使用分離，但增加新的具體產品需要修改工廠類的判斷邏輯代碼，違背開閉原則。
為瞭解決這些缺點，就有了工廠方法模式。
我下回再講工廠方法，今天先到這裡了！
