創建型模式
創建型模式不同於其他模式，因為程序語言本身是支持創建對象實例的
比如使用new關鍵字，比如通過反射創建，通過clone()方法創建對象
也可以在構造方法中對創建邏輯進行干預
那么，為什么還需要創建型模式？
創建型概念特點
先看下前文說過的創建型模式概念
|
創建型模式是用來創建對象的模式，抽象了實例化的過程，封裝了創建邏輯
1. 將系統所使用的具體類的信息封裝起來
2. 隱藏了類的實例是如何被創建和組織的
|
實例的創建與使用分離
創建型模式的最基本功能就是將對象的創建和使用進行了分離
客戶端程序不在關注對象的創建，通過創建型模式進行對象的獲取
對象的創建和使用分離就能保證，對象的創建過程全部都被封裝在創建型模式之中了
不再會散亂的存在於使用的類中，
更加便於維護，也符合依賴倒置原則
隱藏細節類型
一旦使用創建型模式，就
對客戶端程序隱藏了對象創建的細節
甚至可以隱藏對象的具體類型，客戶端程序可以僅僅面向抽象編程即可
不需要關注實際使用對象的具體類型，
降低了耦合度
邏輯清晰 個性化
構造方法雖然可以封裝創建初始化邏輯
但是，構造方法全都是一樣的名字，使用創建型模式---比如工廠模式的話，你哪怕什么都不做
只是給多種用途的構造方法設置更加有自解釋含義清晰的名字，都會
增加可讀性
另外
比如創建型的單例模式，僅僅返回一個對象的實例，如果將這種邏輯植入到構造方法中
將會顯得不倫不類，因為new關鍵字構造方法就是單純的創建對象
不應該將過多的業務邏輯植入其中，它僅適合用於一些初始化操作
使用單獨的創建型模式，
邏輯更加清晰
場景
當你需要對客戶端程序
隱藏實際的對象類型時
當你想要
隱藏實例對象的業務創建邏輯時
當你想要
把對象的使用與創建進行分離時
等等想要
更加個性化定制對象的創建過程的時候
都可以考慮使用創建型模式
簡單工廠模式
而工廠模式是簡單常用的一種創建型模式
概念
工廠模式是最基本的創建型模式，他有三種形式，
簡單工廠，工廠方法，抽象工廠
其中最基本的是簡單工廠形式，
簡單工廠形式簡單到很多時候不被稱為一種模式，更像是一種經驗習慣
簡單工廠模式借助於工廠類的靜態方法，根據參數的不同情況創建不同的對象
簡言之就是：有一個類，他有一個靜態方法， 這個靜態方法根據條件判斷需要創建的對象的類型
示例代碼
|
考慮下面的這種場景
有水果類（抽象類、接口）Fruit用於描述水果
另有具體的水果（實現類）蘋果Apple 橘子Orange
有一個簡單的水果店SimpleFruitFactory 能夠銷售提供所有的水果
|
ps：包名不應該有大寫，應該盡可能地使用一個單詞，實在無法避免也不要駝峰命名，全部小寫
package simpleFactory; /** * Created by noteless on 2018/10/9. * Description: */ public interface Fruit { String description(); }
package simpleFactory; /** * Created by noteless on 2018/10/9. * Description: */ public class Apple implements Fruit { @Override public String description() { return "apple"; } }
package simpleFactory; /** * Created by noteless on 2018/10/9. * Description: */ public class Orange implements Fruit { @Override public String description() { return "Orange"; } }
package simpleFactory; /** * Created by noteless on 2018/10/9. * Description: */ public enum FruitType { APPLE, ORANGE }
package simpleFactory; /** * Created by noteless on 2018/10/9. * Description: */ public class SimpleFruitFactory { public static Fruit create(FruitType fruitType){ if(fruitType.equals(FruitType.APPLE)){ return new Apple(); }else if(fruitType.equals(FruitType.ORANGE)){ return new Orange(); } return null; } }
測試代碼
結構
通過示例可以看得出來，簡單工廠模式的確很簡單
關鍵點就是這個靜態create方法，內部使用if else結構或者switch結構
由於通常都是靜態方法，所以又叫做靜態工廠方法模式
模式如下圖所示
工廠類根據傳入的參數決定創建哪一種類型的具體產品
工廠類Factory
一般就是具體的Java實現類，在客戶端程序的請求下直接創建具體的產品，提供靜態工廠方法
抽象產品 Product
工廠所創建對象的父類或者公共接口，一般是接口或者抽象類
具體產品 ConcreteProduct
創建的具體的實例對象
特點
簡單工廠模式特點：
靜態方法、
根據參數確定待創建對象的類型
當然，也可以不在一個方法中處理，
也可以創建多個方法來創建不同的具體產品對象
而且，如果產品只有一種的話，也可以省略抽象的產品Product角色
簡單工廠模式
處於產品實例化的核心位置
他知道每個產品，也就是內部直接清楚創建的對象類型
他決定哪一個產品類應該被實例化
允許客戶端程序與具體產品的創建過程獨立，在系統引入新產品時，不需要修改客戶端代碼
所以說站在客戶端程序的視角看待的話， 算是符合開閉原則
對於簡單的場景，簡單工廠模式是一個不錯的選擇，既能夠獲得工廠型模式的優點
又足夠的簡便清晰
簡單工廠模式根本特點就是一個工廠類包打天下，創建所有的產品
簡單工廠模式缺點
既然叫做簡單工廠模式，他的優點之一自然是簡單
所有的創建邏輯都封裝在了一個工廠類中，以不變應萬變，所有產品的創建都盡在其中
但是
面對復雜的產品體系結構，優點就變成了缺點 ，可能就會過於臃腫復雜不易維護復用
比如，如果新增加了子類，怎么辦？
顯然需要修改工廠的靜態方法
想要擴展功能必須修改工廠類的代碼，也就是
站在工廠類的角度，不符合開閉原則
而且，面對復雜的產品體系結構，這個工廠類提供所有的創建邏輯
成了一個功能大而全的類，顯然這
違背了單一職責原則
也會更容易出現問題