這樣當我們需要增加或刪除新的Duck的子類的時候，每次都必須要來修改這裡的程式碼，會造成系統難以維護和更新；
解決方法：這時候我們就需要引入工廠模式；

工廠模式：
作用：代替了new物件；
好處：① new物件的話，一旦程式碼有變化或者拓展，就必須改變原來的程式碼，也就是說你的程式碼並“對修改關閉”；ps：設計原則之一：對擴充套件開放，對修改關閉；
             ② 解耦，便於更新和維護；


工廠模式分類：
簡單工廠模式（不是一個真正的設計模式，更像是一種程式設計習慣）
做法：建立一個簡單工廠SimpleDuckFactory，把建立物件的程式碼移到SimpleDuckFactory中;

這時候我們的Duck類就需要引入工廠，如下：

簡單工廠的優點：
通過使用工廠類,外界可以從直接建立具體產品物件的尷尬局面擺脫出來,僅僅需要負責“消費”物件就可以了。而不必管這些物件究竟如何建立及如何組織的；
明確了各自的職責和權利，有利於整個軟體體系結構的優化；

簡單工廠的缺點：
1：擴充套件性差，增加不同的子類還需要修改工廠方法；
2：不同的產品需要不同的額外引數的時候不支援；

附UML：

工廠方法模式：
讓子類做決定！
如何做？
所要做的事情就是把工廠方法中的createDuck放回到DuckStore中，不過要把設定為抽象方法，然後為每個地區建立一個DuckStore的子類；
如下：

想要在建立不同子類物件，得先有鴨子類及其子類才行，不同的鴨子種類讓子類去實現

測試：

工廠方法模式總結：
① 定義了一個建立物件的介面，但由子類來決定例項化哪一個，工廠方法讓類把例項化推遲到子類；
② 工廠方法就是抽象類提供的一個建立物件的方法的介面；

UML：

工廠方法存在的問題：高層元件(DuckStore)依賴於底層元件(Duck)；（高層元件是指由其他底層元件定義其行為的類）；
ps:設計原則之一：要依賴抽象，不要依賴具體類；不管高層或底層元件，都應該依賴於抽象；


抽象工廠模式：
提供一個介面，用於建立相關或依賴物件的家族，而不需要明確指定具體類；

比如說我們需要給鴨子增加原料產品，原料分地區又分很多種，所以需要定義一個介面來建立多個原料；

建立不同的類來實現原料方法；

亞洲原料：

 非洲原料：

這時候需要在Duck類中加入原料資訊：

子類的構造器中需要引入原料工廠：

這樣一來，原料產品就和客戶端解耦了，抽象工廠允許客戶使用抽象的介面來建立一組相關的產品，而不需要知道實際創建出的產品
是什麼。

UML:關係較為複雜

本人小菜鳥一隻，這只是個人對工廠模式的一些理解， 如有不足請指正，定虛心受教。