簡單工廠
工廠方法
抽象工廠
總結對比
我們使用設計模式目的無非隻有三個：a)縮短開發時間；b)降低維護成本；c)在應用程式之間和内部輕松內建。具體什麼時候使用何種設計模式還得因項目而異。
簡單工廠、工廠方法和抽象工廠都屬于設計模式建立型，嚴格意義上簡單工廠不屬于23設計模式之一（違背了開閉原則）。
一、簡單工廠：
概念：說的通俗些就是工廠根據不同的參數建立對應的産品。
栗子：有個簡單工廠是負責計算的 我傳一個加号就傳回一個算加法的電腦、我傳一個減号就傳回一個算減法的電腦。
在沒有工廠之前，大家都是自給自足，生産一部車或其他工具都是自己來完成，有了工廠之後，告訴它需求就會出來相應的産品，但生産化水準比較低，工廠分工不太明确，社會上隻有一個工廠，不論卡車還是公共汽車都由它來完成，相當于一個工廠多條生産線。
好處：工廠類包含邏輯判斷，根據用戶端執行個體化相關類，去除與具體産品依賴，用戶端不管哪個類的執行個體，把需求給工廠，工廠單獨建立相應執行個體。是優點也是不足。
不足：如果添加産品，需要修改工廠類，違背開閉原則。工廠方法的出現解決了這一困惑。
二、工廠方法：
概念：工廠方法有别于簡單工廠卻是簡單工廠的更新。
不同之處、簡單工廠是通過參數來控制産品的生産、這裡使用的是重載。不同的工廠實作同一個工廠方法生産不同的産品、是一個工廠生産一個産品(一對一)。如需增加産品、首先要增加工廠。是一對一的生産模式。
栗子：一個抽象工廠是負責計算的。如果需要生産一個計算加法的電腦、首先就要有一個隻生産加法電腦的工廠。如果要生産一個計算減法的電腦、就要有一個生産減法電腦的工廠。
随着專業化程度的提高，工廠分工變得明确，每個工廠生産各自的産品，公共汽車工廠隻管生産公共汽車，卡車工廠負責生産卡車，這樣如果有新的産品需求，直接增加相應的産品類和對應 工廠類即可。和簡單工廠不同的是，多了一個抽象工廠接口，具體工廠類都來實作它。用戶端也來執行個體化具體工廠類（聲明時候是父類）。
好處：遵守開閉原則，直接添加具體産品類和相應工廠類，執行個體化哪一個工廠放在用戶端
不足：第一：增加一個産品就要增加一個産品工廠類，額外開發，第二：把簡單工廠内部邏輯移到用戶端，是以之前修改工廠類，現在修改用戶端，問題還是存在，抽象工廠的出現了。
三、抽象工廠：
概念：說的簡潔些抽象工廠就是 簡單工廠+工廠方法。
工廠方法雖解決簡單工廠違背開閉原則的問題，但它每個工廠隻能生産一種産品，對于系列産品表示無能為力，而且大家都看到工廠能獲益，随着工廠的增多，使用者的需求，這時有了品牌的概念，比如想要寶馬的卡車，奔馳的公共汽車等。
好處：一、可以解決工廠方法每個工廠隻能生産單一産品的工廠，根據産品需求進一步抽象出一個工廠類的抽象類，是以為抽象工廠。通過改變具體工廠使用不同産品配置。二、具體建立執行個體過程與用戶端分離，用戶端通過抽象接口操縱執行個體，
不足：增加新産品，比如上圖大衆的轎車，就要添加轎車抽象類，和下面的大衆轎車，大衆卡車等，還有修改抽象工廠，和具體的工廠，比如上圖就要添加大衆的具體工廠，要修改的地方太多啦，這時就顯得糟糕了，不過可以通過簡單工廠改進抽象工廠。
抽象工廠的改進（更換資料庫的問題）：
簡單工廠改進抽象工廠：一個database類，可以建立iuser和idepartment的sql和access産品，如果需要更換oracle資料庫呢？又需要在database中修改case分支，添加oracle資料庫的分支判斷，違背開閉原則，不好維護，這時把資料庫作為字元串拿出來，反射出場了。
反射+抽象工廠：assembly.load(程式集).createinstance（命名空間.要執行個體化類名稱），原來寫死在程式裡，現在字元串來是執行個體化對象（變量可以更換），資料庫使用由db決定，去除database中switch判斷，不過還需要改程式中db的值，不完美，有沒有一種不修改程式的方法，當然可以讀取配置檔案啊。
配置檔案+反射：真正符合開閉原則，讀檔案時給DB字元串指派，寫明用sql還是access，這樣database也不用更改啦。
四、總結對比：
簡單工廠：一個工廠，生成各種不同class的對象。一般來說這些對象應該某一基類或接口關聯的，除非你牛就聲明傳回Object。
工廠方法：多種工廠，按需選擇一工廠生成對象。這些工廠之間靠擁有同一接口方法關聯，是以叫“工廠方法”模式。
抽象工廠：多種工廠協作，生成多種class關系不大的對象。常見的處理是把這些對象整體打包提供給你。
每種模式都有自己的優點和弊端，隻有最适合它的場景，沒有最好的時候，隻要滿足自己的需求就是最好的。