主要的用途是把相同的需求或功能拆分成不同的類別，或著是所謂的不同的系列。
讓程式在一開始的時候，可以拿到某一個系列的工廠實作，接下來從這個拿到的工廠所拿到的各個類別實作，就都能確保是屬於同一個系列。
這個模式每次看相關書的時候，都能看到各種不同的情境例子。例如：
而最近看的軟體就該是軟的：設計模式思維實踐貨運物流例子也是蠻不錯的，剛好也筆記下來。
假設公司有提供宅配的服務，然後同時跟多間快遞公司（例如：黑貓、新竹物流、順豐）都有配合。這時候每一家快遞基本上都會有寄件、付款、取件通知……各種一樣的功能（只差在各家的實作跟接口會不同）。
這時候就可以把這些各種功能整理起來，往上抽一層，做成各個不同系列的 factory 類別。讓主程式在使用時，都是那些已經被往上抽的介面。
像是主程式只管使用 IFactory，因為只要在一開始的時候拿到的工廠實作正確，基本上後面所產生的各種功能實作類別，就一定都會是同一個系列的。
個人覺得這個模式比較像是要決定往上抽的範圍要多大。假設沒有套用抽象工廠的模式，以上面情境所提到的物流例子，寄貨或付款基本上也可以是獨立二個功能，然後各自往上抽。比如在準備要用寄貨功能時，再依當時的資料來決定要使用哪一間物流公司的寄貨實作。
同理，當另外要使用付款功能時，也是再依當時的資料來決定要使用哪一間物流公司的寄貨實作。
這樣的實作也可以達到相同的效果（但功能越多的時候，就會有一堆這種依資料判斷實作的地方），只是寄貨和付款基本上是被「完全分開」，彼此沒有什麼關聯存在。
而抽象工廠則是大範圍的把這些一系列的功能綑起來往上抽了一層，然後變成所謂一個系列的家族實作。
其實在實務中，倒是沒有真的在專案裡用過抽象工廠這個模式（可能跟專案或產品有關）。只是隨著工作時間久了，每次看到這個模式的時候，就越來越有 Fu 能夠理解它有機會用在什麼樣的地方。
使用抽象工廠模式時應該是各個系列的功能相似度都很高才對。這時候如果有某個系列突然有個「特例」需求，但是是其他系列都不需要的，不曉得在這模式裡要如何不太破壞它的結構，又能讓這個特例存在？
參考資料
Design Patterns: Abstract Factory
軟體就該是軟的：設計模式思維實踐
不寫個部落格都不知道怎麼換工作
iThome鐵人賽
看影片追技術