引言：讓我們重溫經典，致敬經典

工廠方法模式：定義一個用於創建對象的接口，讓子類來決定實例化哪一個類，工廠方法使一個類的實例化延遲到了子類。

UML圖:

 1 package com.dzf.designtest;
 2 
 3 /**
 4  * <desc>
 5  *     工廠方法：定義一個創建對象的接口，讓子類來決定實例化哪一個類，工廠方法使一個類的實例延遲到子類。
 6  * </desc>
 7  * @author dingzf
 8  * @date 2018/4/1
 9  * @time 21:42
10  */
11 public class FactoryMethodDmeo {
 
12     //客戶端
13     public static void main(String[] args) {
14         ProductFactory productFactory = new ProductImplOneFactory();
15         Product product = productFactory.getInstance();
16         product.operation();
17     }
18 }
19 
20 abstract class Product {
21     public abstract void operation();
 
22 }
23 
24 class ProductImplOne extends Product {
25     @Override
26     public void operation() {
27         System.out.println("我是產品1號");
28     }
29 }
30 
31 class ProductImplTwo extends Product {
32     @Override
33     public void operation() {
34         System.out.println("我是產品2號");
35     }
 
36 }
37 
38 interface ProductFactory {
39     //定義創建對象的接口，再子類中去實例化目標對像
40     public Product getInstance();
41 }
42 class ProductImplOneFactory implements ProductFactory {
43     //子類實例化目標對象
44     @Override
45     public Product getInstance() {
46         return new ProductImplOne();
47      }
48 }
49 class ProductImplTwoFactory implements ProductFactory{
50     //子類實例化目標對象
51     @Override
52     public Product getInstance() {
53         return new ProductImplTwo();
54     }
55 }

解讀：我們知道簡單工廠模式和工廠方法模式很像，但是又不同。

簡單工廠最大的優點在於工廠類中包含了必要性的邏輯判斷，根據客戶端的選擇動態的實例化對象，對於客戶端來說，去除了和具體產品的依賴。但是我們增加功能的時候，是要改變工廠類中的邏輯判斷的。這就違背了開放封閉原則。於是工廠方法就來了。記得在開放封閉原則那篇裏說過，在剛開始的時候，我們不知道什麽是會變的，很難預測，當類中的某些行為發生變化的時候，我們可以把這些抽象出來，防止以後發生同樣的變化。工廠方法模式就是對這句話的詮釋！

工廠方法模式是簡單工廠的進一步抽象，由於使用多態，保持了原有簡單工廠的優點，而且客服了它的缺點，但是每增加一個產品，就需要增加一個與之相對應的工廠類，額外的增加了開發的工作量。有沒有更兩全齊美的辦法呢，答案肯定是有的。不在本篇範圍了，後面再說吧！

工廠方法就先到這吧。

大話設計模式之工廠方法模式讀後感