在《c++設計模式之工廠方法模式》一文中我們提到，由於簡單工廠模式當中的工廠類職責過重，嚴重違反了單一職責的原則，導致系統擴充套件十分困難，於是引出了工廠方法模式，工廠方法模式引入抽象的工廠類，具體的建立工作推遲到每個具體的工廠類中，這樣每個具體工廠類只負責一種產品的建立，這樣每個具體工廠類的職責就足夠單一，足夠簡單了。而工廠方法模式的缺點也**於此：類的職責太單一了，導致要完成系統所需的建立工作，在產品型別增加的時候，工廠類也會急劇增加，導致系統中的類過多。那怎麼辦呢？解決方法很簡單：讓具體工廠類負責更多的工作，也就是負責不止一種型別的具體產品建立。而是負責乙個系列的產品建立。
可是這裡問題又來了：這樣的模式和簡單工廠又有什麼區別呢？豈不是又違反了單一職責的原則嗎？
答： 1. 簡單工廠模式是利用乙個工廠類進行系統中所有的產品類行進行建立，而抽象工廠模式則是利用乙個工廠類進行乙個系列的產品建立。假設有產品手機為諾基亞n系列：n97，n70，n80。諾基亞s系列：6260s,6500s,6700s和諾基亞e50，e61，e71手機。簡單工廠利用乙個工廠建立了：n97，n70，n80，6260s,6500s,6700s，e50，e61，e71。而抽象工廠模式分別用三個具體工廠類：nfactory、sfactory、efactory，分別建立了n系列，s系列，e系列的手機。
2. 正如我在《單一職責和黎克特制替換》一文中說的：如何劃分職責只能在具體場景中進行具體劃分，不同的需求下，劃分可能是不同的。在簡單工廠模式、工廠方法模式，抽象工廠模式中，對於職責的劃分分別為：以建立產品為職責，以建立一種產品為職責，一建立乙個系列的產品為職責，三種工廠模式的職責劃分粒度不同。說到底在何種場合下使用哪種工廠模式，主要看職責劃分是否合理。劃分職責時，粒度不能太大，也不能太小。粒度太大導致單個類職責過重，難以維護，粒度太小導致類的數量太多，系統變複雜。
在抽象工廠模式中，我們然具體工廠類負責更多的職責，在每乙個具體工廠類負責同乙個產品等級下的所有產品族產品的建立。例如linux和windows處於同乙個產品等級，而linux pc版本和linux移動版本是linux這個產品等級下的產品族。這樣抽象工廠模式的uml類圖如下所示：
示例**如下：
#include
#include
//產品等級結構a
class producta
};//產品等級結構b
class productb
};//產品族1
class producta1 : public producta
};//產品族2
class producta2 : public producta
};//產品族1
class productb1 : public productb
};//產品族2
class productb2 : public productb
};class factory
};class factory1: public factory
virtual productb *createproductb()
};class factory2: public factory
virtual productb *createproductb()
}; int main(void)
執行結果：
producta1
productb1
producta2
productb2
使用場景：由上面的闡述知道，當產品等級結構穩定的時候，可以使用抽象工廠方法模式。
C 設計模式之抽象工廠模式
抽象工廠模式 比工廠模式具有更高層次的抽象性，當要返回一系列相關類中的某一格，而對每個類都能根據需要返回不同的物件時候，這種模式就派上了用場。換言之，抽象工廠是乙個工廠物件。它能返回一系列相關類中的某一格，可以用簡單工廠決定哪乙個類。下面這個例子作為抽象工廠模式的例子，希望能跟大家一起分享一起進步。...
c 設計模式之 抽象工廠模式
概念 抽象工廠模式提供了乙個建立相似或相關相互依賴的物件，而不需要說明其具體的實現.類結構圖 圖來自 wiki 示例 include class button class winbutton public button class macbutton public button class scro...
C 設計模式之抽象工廠模式
之前講到了c 設計模式 工廠方法模式，我們可能會想到，後期產品會越來越多了，建立的工廠也會越來越多，工廠進行了增長，工廠變的凌亂而難於管理 由於工廠方法模式建立的物件都是繼承於product的，所以工廠方法模式中，每個工廠只能建立單一種類的產品，當需要生產一種全新的產品 不繼承自product 時，...