創建模式包括 ：簡單工廠模式，工廠方法模式，抽象工廠模式，單例模式，多例模式，建造模式，原始模型模式
簡單工廠模式：負責將大量的 有公共接口的類 實例化，動態決定要將哪個類實例化。又稱靜態工廠方法模式。
有時候把工廠類與抽象類合併，由抽象類提供其子類的創建方法。
工廠方法對以做到對象的循環使用，對其所創建的對像進行登記。（使用私有靜態屬性 -- 單例模式，或者集合存儲 -- 多例模式）
好處： 1 可以使用字符串來創建對象
缺點： 1 當工廠需要創建的產品的層次多重而且複雜，那麼工廠就成了“上帝類”那麼當這個上帝類不能正常工作的時候，就要出問題了。
2 簡單工廠使用靜態方法來創建產品，而靜態方法不能被繼承，所以無法形成基於繼承的等級結構。
簡單工廠與開閉原則：當加入一個新產品的時候，消費者無需修改，但是工廠的修改確實比較痛苦，他必須知道所有產品的創建細節。
針對抽象編程：結合工廠模式，如果將來有新的具體類加入，那麼可以用新類替換原來交給客戶的對象，而客戶端不必修改。
工廠方法模式 ：創建工廠接口，將實際創建工作推遲到子類。（集合的 iterator （）方法就是工廠方法）
簡單工廠模式的缺點 -- 對開閉原則的支持不夠，如果有新類加入，就需要修改工廠方法，將必要的邏輯加入到工廠類。
使用工廠方法模式：當出現一個新類的時候只需要增加一個相應的工廠，而不必對系統作出修改（有必要嗎？有的時候修改並不麻煩啊？）
可以根據產品的等級結構，創建相應等級結構的工廠。
在使用了設計模式的時候，命名應該注意，要讓人一看就知道使用了某種設計模式
工廠方法返回的類型應該是抽象類，而不是具體類
抽象工廠模式 ：針對多個產品等級結構，而工廠方法模式針對一個產品等級結構。
一個等級的工廠可以創建出不同產品等級結構中同一個產品族的所有的產品。
使用抽象工廠模式的時機：
1 一個系統的產品有多於一個的產品族（例如 Oracle 和 DB2 ）而系統只消費其中某一族的產品（我們的 Team 和 Share 的 service ）
2 同一個產品族的產品是在一起使用的（ Share Service 的實現）
3 系統提供一個抽象的產品類庫，客戶端不依賴於產品的具體實現（ Connector 中的 Service Extension ）
如果需要增加產品族，只需要增加相應的具體工廠即可。但是如果要增加新的產品等級結構，就要在每個工廠裏面增加新的方法。所以抽象工廠模式爲產品族的擴展提供了開閉原則，但是不能適應產品等級結構。
在實現當中，具體的工廠類可以設計爲單例模式！
之前，在簡單工廠模式中提過可以用產品的抽象類充當具體產品的工廠。同樣我們可以把抽象的工廠類，變成具體工廠的“工廠”（用靜態方法返還具體工廠的實例，根據參量來決定應該返還哪個產品族的方法）
單例模式
餓漢式單例： public static Singleton singleton = new Singlieton();
懶漢式單例： public static Singleton singleton = null;
登記式單例：子類的構造器是 public 的，這事登記式單例的一個缺點；父類必須存在才能構造子類，這是另外一個缺點。
多例模式
在實例不多的時候 可以使用 靜態屬性來存儲，但是當數目比較多的時候可以用靜態聚集來登記
建造模式
1產品擁有複雜的內部結構
2產品的某一個屬性必須在另一個屬性賦值之後才能被賦值
使用建造模式的好處：
使用建造模式，使得產品內部的零件可以單獨的變化，客戶端不必知道產品的內部細節。
原型模式（這也能算設計模式？）
Object clone(): 1 x!=x.clone()
2 x.getClass()==x.clone().getClass()
3 x.equalse(x.clone())
淺複製：所有的屬性都複製，所有對對象的引用全部指向原型的（從Object繼承過來的clone（）就是淺克隆）
深克隆：多有對象的引用也全都使用克隆。（再用深克隆的時候，要決定深克隆的深度，對間接複製的對象要克隆到多深）