工廠，又稱制造廠，是一類用以生產貨物的大型工業建筑物。大部分工廠都擁有以大型機器或設備構成的生產線。在世界近代史中泛指資本主義機器大生產，即使用機械化勞動代替手工勞動的資本主義工業場所。在我們設計模式中也生活著這么一家人，他們分別是簡單工廠模式，工廠方法模式和抽象工廠模式，他們都是屬于創建型設計模式，這三種創建型模式都不需要知道具體類。我們掌握一種思想，就是在創建一個對象時，需要把容易發生變化的地方給封裝起來，來控制變化（哪里變化，封裝哪里），以適應客戶的變動，項目的擴展。這三種模式按照可維護可擴展的特點來看，工廠方法模式是簡單工廠模式的進化，而抽象工廠模式，又是工廠方法模式的進化。 舉個簡單的例子，春天是播種的季節，我想此刻在我的家-美麗的遙遠的安徽，爺爺奶奶正在菜園子里忙著種植蔬菜苗，如果，奶奶只想讓菜園單純的只要種上蔬菜就可以了，那么就用簡單工廠，奶奶養育了四個兒女，大過年的一大家子人回來，奶奶總想讓那方團圓桌擺上各式各樣的菜肴，這個時候就需要用工廠方法才可以實現，就是把共有的東西抽象出來，菜的種類多了，需要的土地規模就會擴大，如果要擴大菜園子的規模,比如一個在村頭,一個在村尾,這樣工廠方法就無法實現了,就應當用抽象工廠,各種各樣的蔬菜,又組成一個菜園子。接下來，依次來講解一下，三個工廠，依然以我們上述例子： 首先簡單工廠模式，?我們把簡單工廠模式比喻成菜園子，菜園子有他自己的屬性方法，他封轉了澆水，施肥，鋤草三個方法，要求類是客戶端，她只需要調用農活類和菜園子類就可以完成任務，而不需要 一次調用澆水，施肥，鋤草所以，實現了封裝。一起來看一下她的類圖： ? ? ? ?? 如果菜園子中蔬菜的種類越來越多，比如過長豆角，黃瓜，葫蘆等這些蔬菜屬于攀藤類蔬菜，需要支撐架來支撐她們來進行持續生長，茄子，茼蒿這些蔬菜需要定時削剪叉枝，以保持主干支的養分，這個時候，我們就需要修改代碼，首先，我們需要增加支撐架，削剪的類，然后，在菜園子類中改變select或者是if條件分支語句，這樣，不僅增加了類，還需要修改原有的類，這樣一來，違背了開放-封閉原則，這也就是為什么簡單工廠模式不能列入GOF的23中模式的原因之一。 而此時，我們需要把簡單工廠模式中的“菜園子”類加以改進，讓她符合開放-封閉原則，也就是取出她的select case選擇分支語句，讓在增加方法的時候只需要添加類，這樣便符合開閉原則，而簡單工廠和工程方法的區別，也就在此，看看我們的類圖是如何實現的。 ? ? ? ? ? ? ? ? ?? ? ? ? ? ? 我們一直都在寫一個菜園子的農作物，但是，如果需要寫村頭和村尾兩個菜園子的農作物，而且我們可以隨時切換知道兩個菜園子的農作物情況，那么，我們就應該考慮擴充工廠方法模式，而需求不斷演化的過程中，我們就重構了一個非常重要的設計模式：抽象工廠模式，類圖如下： ? ? ? ? ?? ? ? ? ? ? ? 無論是簡單工廠模式、工廠模式還是抽象工廠模式，它們本質上都是將不變的部分提取出來，將可變的部分留作接口，以達到最大程度上的復用。拿一個生產水杯（cup）的工廠舉例：起初，不用工廠模式，我必須在生產水杯之前知道水杯的材料和形狀等水杯的所有特征才能生產，這就是我們的new Cup();這個Cup必須是具體的。 廠主發現同一形狀的被子，只是材料不同,如一個是玻璃(glass)的，一個是瓷(china)的,但是確要兩條生產線，顯然有資源浪費的嫌疑。現在廠主生產杯子時先不讓生產線知道我要產的是玻璃的還是瓷的，而是讓它在不知道具體材料的情況下先做它能做的，等到它把模具做好，只需要向其中填充玻璃原料或者瓷原料就可以造出同一形狀的具體杯子了。所以就有了簡單工廠模式。原來是Cup cup=new Cup;現在是SimpleCupFactory.createCup(String cupName),根據cup的名字生產Cup,而createCup返回的是一個實現了 Cup接口或抽象類的具體Cup。 簡單抽象工廠模式有一個問題，就是當我現在想生產一個同樣形狀的鐵杯時，工廠里并沒有定義相應的處理流程，只能更改createCup方法，這就不合理了。我現在只是想生產鐵杯，你只要在最后的時候把玻璃原料換成鐵的不就行了嗎，干嘛還要更改整條生產線呢？于是就有了工廠模式。原來生產線在生產模具的時候還要考慮是為玻璃杯生產的模具還是為鐵杯生產的模具，現在它不用管了。CupFactory.createCup()創建Cup.CupFactory是接口或抽象類。實現它的具體子類會創建符合Cup接口的具體Cup。那么現在廠主想要生產水壺(kettle)，用工廠模式就不得不再造一條水壺生產線，能不能在水杯生產線同時生產水壺呢？這就是抽象工廠模式。在原CupFactory中加一個createKettle()方法，用來生產水壺。設計之旅，未完待續......