問題：當有一群相關的具體類時（假設擁有duckstore類，duck類及其子類redduck，whiteduck，blackduck），我們建立物件是這樣的：
這樣當我們需要增加或刪除新的duck的子類的時候，每次都必須要來修改這裡的**，會造成系統難以維護和更新；
解決方法：這時候我們就需要引入工廠模式；
工廠模式：
作用：代替了new物件；
好處：① new物件的話，一旦**有變化或者拓展，就必須改變原來的**，也就是說你的**並「對修改關閉」；ps：設計原則之一：對擴充套件開放，對修改關閉；
② 解耦，便於更新和維護；
工廠模式分類：
簡單工廠模式（不是乙個真正的設計模式，更像是一種程式設計習慣）
做法：建立乙個簡單工廠******duckfactory，把建立物件的**移到******duckfactory中;
這時候我們的duck類就需要引入工廠，如下：
簡單工廠的優點：
通過使用工廠類,外界可以從直接建立具體產品物件的尷尬局面擺脫出來,僅僅需要負責「消費」物件就可以了。而不必管這些物件究竟如何建立及如何組織的；
明確了各自的職責和權利，有利於整個軟體體系結構的優化；
簡單工廠的缺點：
1：擴充套件性差，增加不同的子類還需要修改工廠方法；
2：不同的產品需要不同的額外引數的時候不支援；
附uml：
工廠方法模式：
讓子類做決定！
如何做？
所要做的事情就是把工廠方法中的createduck放回到duckstore中，不過要把設定為抽象方法，然後為每個地區建立乙個duckstore的子類；
如下：
想要在建立不同子類物件，得先有鴨子類及其子類才行，不同的鴨子種類讓子類去實現
測試：
工廠方法模式總結：
① 定義了乙個建立物件的介面，但由子類來決定例項化哪乙個，工廠方法讓類把例項化推遲到子類；
② 工廠方法就是抽象類提供的乙個建立物件的方法的介面；
uml：
工廠方法存在的問題：高層元件(duckstore)依賴於底層元件(duck)；（高層元件是指由其他底層元件定義其行為的類）；
ps:設計原則之一：要依賴抽象，不要依賴具體類；不管高層或底層元件，都應該依賴於抽象；
抽象工廠模式：
提供乙個介面，用於建立相關或依賴物件的家族，而不需要明確指定具體類；
比如說我們需要給鴨子增加原料產品，原料分地區又分很多種，所以需要定義乙個介面來建立多個原料；
建立不同的類來實現原料方法；
亞洲原料：
非洲原料：
這時候需要在duck類中加入原料資訊：
子類的構造器中需要引入原料工廠：
這樣一來，原料產品就和客戶端解耦了，抽象工廠允許客戶使用抽象的介面來建立一組相關的產品，而不需要知道實際建立出的產品
是什麼。
uml:關係較為複雜
本人小菜鳥乙隻，這只是個人對工廠模式的一些理解， 如有不足請指正，定虛心受教。
對工廠模式的理解
工廠模式主要解決的問題在於降低 耦合度，將大量對物件的初始化 抽象為可復用的方法 例如對資料庫的連線，可能要使用mysql，可能要使用oracel，可能要使用sqlite，可能這三者要同時使用。使用在業務體中現場例項化的方法的話，乙個過程不嫌複雜，兩個過程也不嫌複雜，如果有多個相同過程時，對具體物件...
讀工廠模式個人理解
最近在 上學習設計模式的使用。工廠模式屬於建立型模式。建立型模式提供了一種建立物件的同時隱藏建立邏輯的方法，簡單理解就是，對alloc乙個物件的 進行封裝。工廠模式 意圖定義乙個建立物件的介面，讓其子類自己決定例項化哪乙個工廠類，工廠模式使其建立過程延遲到子類進行。我們明確地計畫不同條件下建立不同例...
抽象工廠模式個人理解
這個東西有點難懂，我也算是一知半解，就先把現在的理解寫一下吧。大學開學第一件事，大家都知道啊，是要軍訓，軍訓之前，有一件事我們都要做，那就是領軍訓的衣服。軍訓服裝分為上衣和下裝，每個人都有這倆件，這裡我們每個人都可以看成是乙個工廠，每個人身上的上衣個下裝是倆個產品族。這時候，學校領導就要安排人給大家...