設計模式之工廠
1.簡單工廠（Simple factory）
2.工廠方法
1.定義
定義了一個創建對象的接口，但由子類決定更要實例化的類是哪一個。工廠方法讓類把實例化推遲到子類。
工廠方法模式能封裝具體類型的實例化。在抽象的Creator中，任何其他實現的方法，都可能創建這個工廠方法所製造出來的產品，==但只有子類真正實現這個工廠方法並創建產品==。
注意：定義中“由子類決定要實例化的類是哪一個”，所謂的“決定”，並不是指模式允許子類在運行時做決定，而是在編寫創建者時，不需要知道實際創建的產品是哪一個。在運行時客戶選擇使用哪個子類，自然就決定了實際創建的產品是什麼。
個人理解：
這個模式的優點有：
把對象的創建放在方法裏，而不是直接new，這樣除了不需要直接new對象（避免了針對實現編程），還能在方法裏添加了各種邏輯，能更精確的控制對象的產生。（如可以添加參數等）
創建者是一個超類（抽象類、接口），產品也是一個超類，在創建者類裏的用於生產產品（創建對象）工廠方法也是抽象的，而且返回值是產品；這意味着：
- 任何實現了創建者類的子類都必須重寫這個工廠方法，不同的子類對這個方法可以有不同的重寫，從而可以生產不同的產品。如果想生產新品種的產品，只需要創建一個新的實現了創建者類的類然後重寫這個方法即可，原來的代碼完全不受影響，很正做到了OCP
- 返回值是抽象的產品，創建類的其他方法可以繼續用這個返回值。根據里氏替換原則，任何父類出現的地方子類都能出現。這就是說，子類返回的產品都能繼續被創建者類的其他方法所使用，做到了面向接口編程。
2.形式
abstract Product factoryMethod(Sring type)工廠方法是抽象的，所以子類必須重寫工廠方法，也就是說，依賴子類重寫的不同來創建不同的對象
必須返回一個產品。超類中定義的方法，通常使用到工廠方法的返回值。（返回值也是超類，這樣就能返回它的所有子類）
- 工廠方法將客戶和實際創建具體產品的代碼分割開來
- 可以有參數，也可以沒有參數. ==參數化的創建方式克服了Factory Method模式一個最顯著的缺陷,就是當具體產品比較多時,我們不得不也建立一系列與之對應的具體構造器. 但是在客戶端我們必須指定參數來決定要創建哪一個類==
2. 依賴倒置原則（Dependency Inversion Principle）
==要依賴抽象，不要依賴具體類！！！==
不能讓高層組件依賴於低層組件，而且，不管高層或者低層，兩者都應該依賴於抽象。
指導方針
變量不可以持有具體類的引用
如果使用直接new對象，就會持有具體類的引用。可以改用工廠來避開這樣的做法。
不要讓類派生字具體類
如果派生自具體類，就會依賴這個具體類。==要派生自一個抽象類或接口。==
不要覆蓋基類中的已經實現的方法。
如果覆蓋基類已經實現了的方法，意味着這個基類並不是一個真正適合被繼承的抽象。==基類中已經實現了的方法，應該由子類共享==！
3.抽象工廠
1.定義
==提供一個接口，用於創建相關或依賴對象的家族，而不需要明確指定具體類。==
允許客戶使用抽象的接口創建一組相關的產品，而不需要知道實際產出的具體產品室什麼。這樣依賴，客戶就從具體的產品中被解耦。
抽象工廠裏內含工廠方法
抽象工廠的任務是==定義一個負責創建一組產品的接口==。接口內的每個方法都負責創建一個產品。
我們利用==實現抽象工廠的子類通過對這些方法不同的重寫來生產具體的產品==。所以在抽象工廠中裏利用工廠方法是實現生產方法是相當自然的做法。
4.對比工廠方法和抽象工廠
工廠方法：目前還不知道將來需要實例化哪些具體類時可以使用
- 利用工廠方法創建對象，需要擴展一個類，並覆蓋它的工廠方法。
- 說白了就是==通過子類來創建對象==。
- 用這種做法，客戶只需要知道他們所使用的抽象類型就可以，而又子類來負責決定具體類型
抽象工廠：想創建產品家族和想讓製造的相關產品集合起來時使用
- 可以把一羣相關的產品（產品家族）集合起來
- 對象的創建被實現在工廠接口所暴露出來的方法中
- 但是缺點是不方便添加新產品（如果要添加新產品，那麼抽象工廠的這個大接口便要改，實現它的子類全部都要改）
- 負責在抽象工廠中創建產品的方法通常是由==工廠方法==來實現！