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