工廠方法一直不懂它的價值，雖然知道它的形式。今天《iOS設計模式解析》+這篇回答突然茅塞頓開。基於我的理解重新解釋一下。
首先構建一下背景
對於一個模塊而言，它提供服務，服務的具體內容外界是不知道的，如餐廳提供喫飯的服務，具體菜是怎麼做出來的外界是不知道的（因爲分工需要，不可能每件事都知道）。這裏服務就是接口interface，具體服務內容就是實現implematation。
然後一個接口可能對應多個服務，同樣是“點菜”，不同的菜區別很大、同一個菜不同的廚師、不同的餐廳區別也很大。所以這裏就存在一系列的區別因素，這些因素共同決定了這個接口到底會選擇什麼樣的實現。
所以你會發現從接口到實現之間的關聯是有一個邏輯判斷的，而工廠方法就是這個邏輯判斷，只是這是服務就是“創建一個對象”。
工廠方法只是特例應用
我現在要創建一個對象，但是我只有一些區別因素，比如造車，我只知道顏色、類別等，基於這些因素如何創建對象的邏輯，我把它寫到一個統一的方法裏，它就是工廠方法。
這麼做的好處是：
- 這個邏輯判斷誰更清楚？創建者還是調用者？肯定是創建者，是它提供了創建對象的服務。
- 使用統一的方法，可以保證判斷邏輯的統一，如果以後要修改這個邏輯，只需要修改一處就可以了。
想象一下不使用工廠方法會怎麼做：
- 每個構建的地方我都來一遍邏輯判斷，寫上N個
if-else，然後需求一變，每個地方都要改 - 每個構建的地方，我都知道具體要哪個對象，我不需要做判斷，直接指定需要的對象構建。如果這個對象是另一個模塊的，這麼做就相當於把構建選擇的邏輯摻雜到裏當前的模塊裏，甚至更明顯的，那個模塊是另一個部分做的，需求變了以後兩個部門都要改代碼，這就會比較亂了。
而使用工廠方法，只要這個方法的聲明不變，那麼使用者就不要修改代碼，需求改變了也只是創建模塊這邊修改。
就像造車（構建對象），我想要一個紅色的大空間的越野車（區別因素），我把需求提交給工廠，工廠給我車。至於工廠怎麼造車的，造了什麼車我是不知道的我也不關心，只要我的需求達到了就可以了。
最核心的問題，目光不要放到創建對象這個事情本身，而是從外界需求到對象選擇之間的這個邏輯身上，還有構建一個統一方法把邏輯流統一的這個出發點上。工廠方法只是“接口+N個實現”的這種模型在“構建對象”上的一個特例而已，它的核心意義並不在“構建對象”這個是事情本身上。
發散
從這個設計上看，我覺得它可以理解爲是“面向接口編程”理念的一個子集。而更廣泛的模型是：一個接口，有N個實現，外界提供一些區別因素，接口就像是大門，實現就像是大門裏的小門，區別因素從大門流入，走進不同的小門。除了工廠模式，還有很多的地方也會這麼做。