工廠模式——貓糧公司的演進
貓糧公司的誕生
陀螺是個程序喵，另起爐灶自己開了公司，為了紀念曾經碼夢為生的歲月，公司起名為「跑碼場」，主要業務是生產貓糧。
一個喵兼顧着研發和運營，終究不是長久之計。於是雇了一個菜喵做學徒，技術怎麼樣並不在意，陀螺最看重的是菜喵的名字—招財。
很快，第一款產品「魚香貓糧」上線，陀螺讓招財寫個線上訂單系統，方便顧客網上下單
招財很快寫出了代碼
測試之後上線，一直運行正常。
過了一段時間，陀螺對招財說：「公司目前正在研發一款牛肉貓糧，並且預計在接下來一段時間會上線「薄荷貓糧」、「雞肉貓糧」等多款新品，你升級一下訂單系統應對一下未來可能發生的改變。」
招財接到任務，重構了原來的代碼，首先創建了抽象的CatFood，之後所有具體口味的貓糧必須繼承該類
接下來依次是各種口味的貓糧對象
最後是下單的邏輯
招財迫不及待地向陀螺展示自己的代碼，並介紹到：「老闆，我的代碼已經能夠滿足未來的動態變化了，如果再有新口味的產品，只需要創建該產品的對象，然後修改一下order()方法就好了！」
陀螺讚賞地點點頭，「看得出來你經過了自己認真的思考，這一點非常好！但是別著急，你有沒有聽說過開閉原則？」
「開閉原則？聽說過，但是僅僅停留在概念上，我記得好像是『對修改關閉，對擴展開放』，當時為了面試背的還是挺熟的，哈哈哈」
「那你對照開閉原則再看一下你的代碼，你覺得你的代碼有什麼問題？」，陀螺問道。
招財趕緊仔細審視了一下自己的代碼，”我知道了，現在的問題是一旦有新產品上線，就需要改動orde()方法，這就是所謂的沒有對修改關閉吧，但是有了新的產品你總得有個地方把他new出來啊，這一步是無論如何都無法省略的，我覺得目前的代碼是能夠滿足需求的。”
「你說的沒錯，設計原則並不是金科玉律，比如未來如果只有零星幾個的新口味產品上線的話，你確實沒有必要改變現在的代碼結構，簡單的修改一下order()就可以了，根本不用在意對修改關閉的這種約束。但是你有必要思考一下，如果後期我們研發了數十種乃至上百種產品，這種情況下你該怎麼做？」
「除了修改order()方法，我實在沒有想出其他的辦法…」，招財撓着腦袋回答道。
陀螺不急不慢地解釋說：「這種時候，我們可以先識別出代碼中哪些是經常變化的部分，然後考慮使用封裝，很明顯，order()方法中創建對象的部分就是經常需要變化的，我們可以將封裝，使其專門用於創造對象。」
陀螺解釋說：「如此一來，我們完成了封裝的操作，把生成對象的操作集中在了SimpleCatFoodFactory中。」
招財立即提出了自己的疑問：「我不理解這樣做有什麼好處，在我看來這只是把一個問題搬到了一個對象里罷了，問題本身依然存在！」
「就創建的過程而言，你說的確實沒錯。」，陀螺點點頭，「但是，我們仍然得到了很多益處，現在我們的SimpleCatFoodFactory不僅僅可以被order()方法使用了，之後的任何相關邏輯都可以調用我們寫的這個類，而且如果後續需要改變，我們也僅僅需要改變這個單獨的類就可以了」。
招財無奈地回應說，「好吧，你的話確實很有道理，把經常變動的部分提取出來是個不錯的代碼優化習慣。對了，剛才這種優化技巧有名字嗎？」
「這種叫簡單工廠，很多開發人員都誤以為它是一種設計模式了，但是它其實並不屬於GoF23種設計模式，但是由於用的人太多，經常把它和工廠模式一起介紹。至於是不是設計模式，對我們而言並不重要。」
簡單工廠並不是一種設計模式，更像是一種編程的優化習慣，用來將對象的創建過程和客戶端程序進行解耦
招財並不放棄，繼續追問，「那能不能有個辦法再優化一下創建對象的過程呢，它現在依然沒有滿足開閉原則！而且客戶端的調用方式非常不優雅，萬一參數不小心拼錯了，直接就崩了，這種麻煩不應該轉嫁到客戶端不是嗎？」
陀螺愣了愣，久久盯着招財，彷彿看到了當年自己剛學習編程的樣子，對一切充滿好奇，對代碼又有點潔癖，欣慰地說道：「說得好啊，那我們嘗試利用反射繼續優化一下吧。」
客戶端的代碼優化如下
「到此SimpleCatFoodFactoryV2就符合了開閉原則，但是這裡利用反射的一個基本原則是所有對象的構造方法必須保持一致，如果對象創建的過程比較複雜而且各有特點，那麼優化到這一步或許並不是最好的選擇，記住優化的原則——合適就好」，陀螺補充道。
招財對陀螺的這一番優化和解說佩服不已，心想實習遇到這麼個好老闆好師傅，平時還能試吃自己最愛的貓糧，這簡直就是在天堂啊。
貓糧公司的擴張
日子一天天過去，公司在陀螺的運營下經營有成，計劃在全國各地建立分公司。為了保證服務質量，陀螺希望各個分公司能夠使用他們經過時間考驗的代碼。
但是不同的分公司需要根據當地特色生產不同口味的產品，比如山東生產「蔥香貓糧」、「大醬貓糧」，湖南生產「辣子貓糧」、「剁椒貓糧」…
招財心想，這不簡單嘛！繼續利用SimpleCatFoodFactoryV2，讓各個公司的新款貓糧繼承CatFood不就可以了嘛！
但是轉念一想，隨着每個分公司的產品鏈的豐富，獲取產品的創建過程會有差異，那麼SimpleCatFoodFactoryV2的職責會變得越來越多，像一個萬能的類，不方便維護。
招財想到可以為每個分公司創建獨立的簡單工廠，然後將具體的簡單工廠對象綁定到PaoMaChang對象中，顧客下單的時候只要指定對應的分公司的工廠和口味就可以進行下單了。
PaoMaChangV3重構如下
將工廠本身也做了個抽象，創建ICatFoodFactory接口
各分公司的工廠代碼
各種口味的貓糧代碼如下
產品類對應的UML圖為
顧客下單「湖南分公司」的「剁椒貓糧」的代碼就變成了這樣
到此，招財重構完了代碼，經過細心檢查系統終於上線了，各地分公司使用這套系統有條不紊地開展起自己的業務，形勢一片大好！
之後的某一天，招財接到陀螺的電話，讓他火速前往陀螺的辦公室，招財一路戰戰兢兢，一直在想是不是自己的代碼出了問題。來到辦公室，陀螺招呼招財來到他旁邊坐着，指着滿屏的代碼說道：「別害怕，你的代碼到目前為止沒有出什麼bug。你為每一個分公司單獨創建自己的簡單工廠，又把簡單工廠對象作為參數注入到了PaoMaChang類中，能看得出來你最近沒少在代碼上下功夫。只是我在審查各分公司代碼的時候發現一個潛在的隱患。」說罷，打開了某分公司的代碼給招財看。
招才看到，湖南分公司的技術人員在order()方法中擅自添加了一個pack()打包的方法，陀螺繼續說道：「先不管這個邏輯加的對不對，光是分公司能夠改動我們的核心代碼這一點就是有風險的，你需要想個辦法，既能讓每個分公司自由創建產品，又能保證我們的核心功能不被改變，核心邏輯只能由我們來定。」
「確實是個問題，目前各個分公司的下單邏輯都是自己定義的，我們需要提供一個真正的「框架」，讓他們按照我們的標準來進行業務邏輯。」
「沒錯！」，陀螺欣慰地看着招財。
「既然如此，我可以把我們的PaoMaChangV3改成抽象的，命名為PaoMaChangV4吧，讓各個子公司繼承這個類，然後為order()添加final關鍵字，禁止子類進行覆寫，這樣他們便只能用我們的下單邏輯了」，招財一遍思考一邊說。
「那你打算怎麼讓子公司能自由控制各種產品呢？」，陀螺問道。
招財不慌不忙地回答：「我最近又研究了一下多態和繼承，order()方法中的create()方法不做具體操作，將該方法延遲到子類中進行執行。」說罷，招財立刻寫了如下代碼。
“order()方法只是調用了create()方法而已，是由子公司創建的子類負責具體實現create()方法，湖南分公司和山東分公司對應的代碼如下”，招財接着解釋道。
對應的UML圖為
最終顧客的下單方式變成了
「看來真是要對你刮目相看了，你剛剛總結出來的這種思想其實就是大名鼎鼎的工廠方法模式」，陀螺滿意地笑了，「工廠方法模式通過讓子類決定該創建的對象是什麼，來達到將對象創建的過程封裝的目的。」
工廠方法模式：定義一個創建對象的接口，擔憂子類決定要實例化的類是哪一個，將類的實例化推遲到了子類。
「啊！」，招財大驚，沒想到自己誤打誤撞研究出了工廠方法模式，「我其實並沒有想這麼多，只是單純想解決當下的問題，適應未來的變化而已。」
「我知道，恐怕現在讓你總結什麼時候該用簡單工廠模式，什麼時候該用工廠方法模式你也未必說的準確。設計模式也不過是前人不斷優化自己的代碼總結出來的方法論。不必拘泥於你的優化方式叫什麼名字，或者乾脆忘掉我剛才說的術語吧，在合適的時機運用合適的方法來解決問題才是最重要的！不要學習了設計模式，就覺得自己手上握着鎚子，然後看什麼都是釘子。」
「我明白了師傅！但是我聽說還有一種關於工廠的設計模式，你要不順便給我講講吧。」
貓糧原材料的工廠
「還有一種叫抽象工廠模式，如果你明白了我們系統的一步步優化，這個模式對你來說就太簡單了。還是用我們公司的場景給你舉例子吧。」
「假如我們想進一步控制分公司生產貓糧的原料，避免每個分公司的原料質量參差不齊。製作貓糧的主要原料都是一樣的，都需要肉、燕麥、果蔬、牛磺酸等，但是不同的分公司又有不同的原料生產工藝，抽象工廠就適合於這種場景。」
「那該怎麼進行設計呢？」
「這個簡單啊，我們可以為每一個分公司創建一個原料工廠，這個原料工廠必須符合我們制定的標準，像這樣」，招財寫下了偽代碼。
“各分公司自己的原料廠必須實現CatFoodIngredientFactory來實現每一個創造方法，以山東分公司為例。”
註：代碼中有很多類未給出實現，大家只需理解其中的含義即可
招財繼續問道：「現在怎麼把各個分公司的原料工廠和貓糧聯繫起來呢？」
「別急，為了更好的解釋抽象工廠，我們需要先改變一下我們的CatFood類。這裡只是為了單純講解抽象工廠模式而進行的更改，和我們自身的業務邏輯已經沒有關係了。」
「接下來的重點就是如何創建具體口味的貓糧了。你覺得怎麼讓貓糧和原料廠關聯起來呢？」
「可以在子類中添加一個原料工廠的對象，貓糧產品對象的時候可以選擇某個原料廠進行初始化，這樣就實現了貓糧和具體原料之間的解耦，貓糧類只需要知道怎麼製作就可以了，比如像這個樣子。」
「孺子可教」，陀螺欣慰地說道，「你已經掌握的面向對象的精髓了，那麼分公司的代碼你也可以寫出來了，試試看吧。」
招財很快寫出了代碼。
「到此為止，我們就用抽象工廠模式完成了業務的改造，顧客下單的邏輯並沒有發生變化。為了完整性，我們給出抽象工廠的定義」，陀螺說道。
抽象工廠模式：提供接口，用來創建相關或依賴對象的家族，而不需要明確制定具體類。
招財鬱悶地說：「你讓我自己寫我覺得自己能寫出來，你解釋這麼多，我反而頭大了！」
「哈哈哈哈哈哈，學習有三種境界，第一種：看山是山，看水是水；第二種：看山不是山，看水不是水；第三種：看山依然山，看水依然水。你現在就處於第一種向第二種過度的階段」，陀螺打趣道。
「我們從頭捋一遍我們系統升級的過程，幫助你理解。」
總結
「剛開始我們公司只生產一種產品——魚香貓糧，這時你直接針對該產品創建類FishCatFood進行業務邏輯編寫即可，不需要進行任何優化。」
「後來公司相繼生產了其他兩種產品，鑒於每種產品產品的相關性，你創建了CatFood抽象類，之後生產的每種產品都需要繼承這個類，然後在order()方法中根據用戶傳入的口味製作相應的產品。但是隨着公司的發展，產品可能會一改再改（急劇增加或下架），order()方法不再滿足開閉原則，因此我們將創建對象的代碼抽離到SimpleCatFoodFactory中進行統一管理，這就是簡單工廠。」
「後來公司相繼在其他省份創建了子公司，每個子公司都有自己的產品，為了避免SimpleCatFoodFactory成為萬能工廠，我們為每個分公司創建了獨立的簡單工廠，按照我們的要求來創建產品對象。」
「我們並不想讓子公司能夠修改order()的中的邏輯，因此我們試圖創建一個『框架』，強制讓子公司使用我們的下單邏輯，同時又保證子公司自由創建產品的靈活性。於是我們在PaoMaChangV4抽象類中使用了抽象的create()方法，我們將實現create()的行為延遲到子類中，父類中制定了基本框架。這一步使得order()不依賴於具體類，換句話說，這就是解耦。當order()方法調用create()方法是，PaoMaChangV4的子類（子公司對象）將負責創建真正的產品。這就是工廠方法模式。」
「最後我們想確保對每個子公司每個產品原料的控制，定義了原料族。這裡有一個隱含的假設，每個產品所使用的原料都是相同的，區別是生產方式不同。」
「我們創建了原料工廠CatFoodIngredientAbstractFactory接口，該接口定義了創建所有原料的接口，再看一下代碼。」
“接下來我們為每個分公司創建了實現了CatFoodIngredientAbstractFactory接口的子類來實現每一個創建方法。為了更恰當地解釋抽象工廠模式，我們又稍微改造了一下貓糧類，得到了CatFoodV2，所有的具體產品依然繼承自CatFoodV2，不同的每個產品都需要從構造器中得到一個原料工廠，注入到對象中的catFoodIngredientFactory變量，CatFoodV2中的make()方法會使用到該工廠創建的原料。”
「最後總結一下抽象工廠模式的使用場景，當你需要使用原料家族來創建想要製造的產品的時候，你就可以考慮使用抽象工廠模式了。」
我是蟬沐風，一個讓你沉迷於技術的講述者，歡迎大家留言！
