一直以來，無論是在面試的時候或者在平時交流，只要涉及到模式，言必稱工廠模式。而在工作中，工廠模式也是我用的最多的兩個模式之一（後面才發現其實是簡單工廠模式）。偶爾翻起曾經看過的書，才覺得很有必要溫習一遍。
其實工廠模式就分為三種：簡單工廠模式、工廠方法模式、抽象工廠模式。
1、簡單工廠模式：
使用率：幾乎是我用的最多的模式之一了，幾乎涉及到我參與設計的所有專案甚至於所有模組。
使用場景：一批具有相同屬性的類，對外提供相同的操作介面，為了對外隱藏類本身，而使用抽象的基類替代。
例項：一般的程式都有列印日誌的需求，有些是寫網路日誌，有些是寫本地檔案，有些是寫資料庫日誌。
分析：最簡單的方式當然是實現三個類( cnetlog, cfilelog, cdblog），然後列印日誌的時候定義相應類的物件並呼叫其write方法。這樣有乙個問題就是所有的日誌操作類必須暴露給使用方(client)，但實際上可能client根本就不關心有那些類，他只關心我能列印這些日誌就行了，至於你裡面是通過幾個類實現還是通過不同的函式實現的他不關心。按照這樣的系統偶合性很大（因為client需要知道所有的打日誌類）。
如果client只需要先獲取乙個需要的例項，然後呼叫該例項的方法來列印日誌，而無需關心其具體的例項是誰？那樣就降低了系統的耦合度。
類關係圖對比：
可以看出，在2圖中，client只需要從clogfactory中獲取乙個clog的例項，然後呼叫該例項的write方法寫日誌即可，也就是client只需要看到clogfactory類和clog，clog是抽象類。而且，以後無論新增什麼列印日誌的新類，只需要新寫乙個類繼承clog並實現其抽象方法write即可，client無需改變，對原來已有的cnetlog, cfilelog, cdblog也無需改變，既保證了對擴充套件開放，又從一定程度上減少了對已有系統的影響。
但是簡單工廠模式，並不能完全遮蔽修改，比如這裡新增乙個新的日誌類，必須修改clogfactory的getinstance()方法，並新加入相應的策略使新類生效。
實現**：
//工廠類
class clogfactory
static public clog* getinstance(const string logtype)
clog* instance = null;
if("net" == logtype)
instance = new cnetlog();
}else if("file" == logtype)
else if("db" == logtype)
else
return instance ;
}//列印日誌抽象類
class clog
public write(const string& strlog) = 0;
class cnetlog
public write(const string& strlog)
class cdblog
public write(const string& strlog)
class cfilelog
public write(const string& strlog)
int main(void)
clog* instance = clogfactory::getinstance("net");
instance->write("hello world.");
return 0;
重讀設計模式 工廠方法模式
說到工廠方法，很容易就想到簡單工廠，而實際上工廠方法也是和簡單工廠有點類似。聯想到簡單工廠模式中的例子，新增乙個日誌類，必須修改clogfactory的靜態方法getinstance 這點就是簡單工廠不能解決的了。工廠模式就是為了解決簡單工廠的這種弊端而改進的。2 工廠方法模式 使用率 使用的較多的...
設計模式 工廠模式（簡單工廠）
一 簡單工廠 定義 簡單工廠模式 factory pattern 屬於類的創新型模式，又叫靜態工廠方法模式 static factorymethod pattern 是通過專門定義乙個類來負責建立其他類的例項，被建立的例項通常都具有共同的父類。特點 工廠類直接實現，乙個產品介面，乙個工廠類可以產生多...
設計模式（簡單工廠模式 工廠模式 抽象工廠模式）
當邏輯較為簡單時，可以直接建立對應的類。如下 include using namespace std class class banana class pear intmain 通過此 可以發現，使用者直接與客戶接觸，違背了dip 依賴倒轉 原則，過於麻煩，所以引出簡單工廠模式。include us...