對「工廠方法」，忽然茅塞頓開

工廠方法一直不懂它的價值，雖然知道它的形式。今天《iOS設計模式解析》+這篇回答忽然茅塞頓開。基於個人理解從新解釋一下。

首先構建一下背景

對於一個模塊而言，它提供服務，服務的具體內容外界是不知道的，如餐廳提供吃飯的服務，具體菜是怎麼作出來的外界是不知道的（由於分工須要，不可能每件事都知道）。這裏服務就是接口interface，具體服務內容就是實現implematation。

而後一個接口可能對應多個服務，一樣是「點菜」，不一樣的菜區別很大、同一個菜不一樣的廚師、不一樣的餐廳區別也很大。因此這裏就存在一系列的區別因素，這些因素共同決定了這個接口到底會選擇什麼樣的實現。

因此你會發現從接口到實現之間的關聯是有一個邏輯判斷的，而工廠方法就是這個邏輯判斷，只是這是服務就是「建立一個對象」。

工廠方法只是特例應用

我如今要建立一個對象，可是我只有一些區別因素，好比造車，我只知道顏色、類別等，基於這些因素如何建立對象的邏輯，我把它寫到一個統一的方法裏，它就是工廠方法。

這麼作的好處是：

1. 這個邏輯判斷誰更清楚？建立者仍是調用者？確定是建立者，是它提供了建立對象的服務。
2. 使用統一的方法，能夠保證判斷邏輯的統一，若是之後要修改這個邏輯，只須要修改一處就能夠了。

想象一下不使用工廠方法會怎麼作：

1. 每一個構建的地方我都來一遍邏輯判斷，寫上N個if-else，而後需求一變，每一個地方都要改
2. 每一個構建的地方，我都知道具體要哪一個對象，我不須要作判斷，直接指定須要的對象構建。若是這個對象是另外一個模塊的，這麼作就至關於把構建選擇的邏輯摻雜到裏當前的模塊裏，甚至更明顯的，那個模塊是另外一個部分作的，需求變了之後兩個部門都要改代碼，這就會比較亂了。

而使用工廠方法，只要這個方法的聲明不變，那麼使用者就不要修改代碼，需求改變了也只是建立模塊這邊修改。

就像造車（構建對象），我想要一個紅色的大空間的越野車（區別因素），我把需求提交給工廠，工廠給我車。至於工廠怎麼造車的，造了什麼車我是不知道的我也不關心，只要個人需求達到了就能夠了。

最核心的問題，目光不要放到建立對象這個事情自己，而是從外界需求到對象選擇之間的這個邏輯身上，還有構建一個統一方法把邏輯流統一的這個出發點上。工廠方法只是「接口+N個實現」的這種模型在「構建對象」上的一個特例而已，它的核心意義並不在「構建對象」這個是事情自己上。

發散

從這個設計上看，我以爲它能夠理解爲是「面向接口編程」理念的一個子集。而更普遍的模型是：一個接口，有N個實現，外界提供一些區別因素，接口就像是大門，實現就像是大門裏的小門，區別因素從大門流入，走進不一樣的小門。除了工廠模式，還有不少的地方也會這麼作。