工廠設計模式（Factory Pattern）
摘要：
在工廠模式中，我們在建立物件時不會對客戶端暴露建立邏輯，並且是通過使用一個共同的介面來指向新建立的物件。
意圖
定義一個建立物件的介面，讓其子類自己決定例項化哪一個工廠類，工廠模式使其建立過程延遲到子類進行。
何時使用
我們明確地計劃不同條件下建立不同例項時。
如何解決
...
在工廠模式中，我們在建立物件時不會對客戶端暴露建立邏輯，並且是通過使用一個共同的介面來指向新建立的物件。
意圖
定義一個建立物件的介面，讓其子類自己決定例項化哪一個工廠類，工廠模式使其建立過程延遲到子類進行。
何時使用
我們明確地計劃不同條件下建立不同例項時。
如何解決
讓其子類實現工廠介面，返回的也是一個抽象的產品。
關鍵程式碼
建立過程在其子類執行。
應用例項
- 您需要一輛汽車，可以直接從工廠裡面提貨，而不用去管這輛汽車是怎麼做出來的，以及這個汽車裡面的具體實現。
- Hibernate 換資料庫只需換方言和驅動就可以。
優點
- 一個呼叫者想建立一個物件，只要知道其名稱就可以了。
- 擴充套件性高，如果想增加一個產品，只要擴充套件一個工廠類就可以。
- 遮蔽產品的具體實現，呼叫者只關心產品的介面。
缺點
每次增加一個產品時，都需要增加一個具體類和物件實現工廠，使得系統中類的個數成倍增加，在一定程度上增加了系統的複雜度，同時也增加了系統具體類的依賴。這並不是什麼好事。
使用場景
- 日誌記錄器：記錄可能記錄到本地硬碟、系統事件、遠端伺服器等，使用者可以選擇記錄日誌到什麼地方。
- 資料庫訪問，當用戶不知道最後系統採用哪一類資料庫，以及資料庫可能有變化時。
- 設計一個連線伺服器的框架，需要三個協議，"POP3"、"IMAP"、"HTTP"，可以把這三個作為產品類，共同實現一個介面。
注意事項
作為一種建立類模式，在任何需要生成複雜物件的地方，都可以使用工廠方法模式。
有一點需要注意的地方就是複雜物件適合使用工廠模式，而簡單物件，特別是只需要通過 new 就可以完成建立的物件，無需使用工廠模式。如果使用工廠模式，就需要引入一個工廠類，會增加系統的複雜度。
實現
factory_pattern_uml_diagram
使用反射來解決工廠類開閉原則的問題。
可參考程式碼 ShapeFactory
public static Shape getshape(String className){
className = shape_PACKAGE + className;
try {
Class c = Class.forName(className);
Constructor constructor = c.getConstructor();
return (Shape) constructor.newInstance();
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (NoSuchMethodException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (InvocationTargetException e) {
e.printStackTrace();
}
return null;
}
這樣，新增加一個圖形的時候，工廠類也不需要做出改變。符合了 開閉原則 （對擴充套件開放，對修改關閉）。
在簡單工廠模式中，對於實現類而言，的確是符合我們的開閉原則，當我們要新增新產品時，無需對業務進行修改，但是對於我們的工廠類而言，開閉原則沒有很好的體現，每次都得修改。