那麼這個抽象工廠又是怎麼一回事呢?
大家聯想一下現實生活中的工廠肯定都是具體的，也就是說每個工廠都會生產某一種具體的產品，那麼抽象工廠意味著生產出來的產品是不確定的，那這豈不是很奇怪? 抽象工廠模式起源於以前對不同抽象系統的圖形化解決方案，如不同作業系統中的按鈕和文字控制項是不一樣的，其實現不同，展示效果也不同。對於乙個作業系統，其本身就構成乙個產品類，而按鈕和文字控制項也構成乙個產品類，兩種產品類兩種變化，各自有自己的特性，如android中的button和textview,ios中的button和textview，window phone中的button和textview等
為建立一組相關或者相互依賴的物件提供乙個介面，而不需要指定它們的具體類。
乙個物件族有相同的約束時可以使用抽象工廠模式。是不是聽起來很抽象? 舉個例子，android，ios,window phone下都有簡訊軟體和撥號軟體，兩者都屬於software軟體的範疇，但是，它們所在的作業系統平台不一樣，即便是同一家公司出品的軟體，其**的實現邏輯也是不同的，這時候就可以考慮使用抽象工廠方法模式來產生android，ios，window phone下的簡訊軟體和撥號軟體。
**實現如下所示：
// 抽象車廠類
public
abstract
class
ca***ctory
/***這裡我們為每一種零部件產品定義乙個介面，並分別建立兩個不同的實現類表 示不同的零部件產品。**/
//輪胎相關類
public
inte***ce
itire
public
class
normalitire
implements
itire
}public
class
suvtire
implements
itire
}//發動機相關類
public
inte***ce
iengine
public
class
chinaengine
implements
iengine
}public
class
importengine
implements
iegine
}//制動系統相關類
public
inte***ce
ibrake
public
class
normalbrake
implements
ibrake
}public
class
seniorbrake
implements
ibrake
}/**
**對於生產q3的工廠，其使用的零部件不同，而生產q7的工廠呢，其零部件也 不同。**/
//q3工廠類
public
class
q3factory
extends
ca***ctory
@override
public iengine createengine()
@override
public ibrake createbrake()
}//q7工廠類
public
class
q3factory
extends
ca***ctory
@override
public iengine createengine()
@override
public ibrake createbrake()
}/**
**最後我們在乙個client客戶類中模擬**/
//客戶類
public
class
client
}
普通輪胎國產發動機
普通制動
越野輪胎
進口發動機
高階制動
上面我們只是模擬了兩個車系q3和q7的工廠，如果此時我們需要增加q5的工廠呢? 那麼定義的輪胎，制動系統和發動機類有要增加，這裡就可以看出抽象工廠方法模式的乙個弊端，就是類的徒增，如果工廠類過多，勢必導致類檔案非常多，因此，在實際開發中一定要權衡慎用
設計模式之工廠模式（簡單工廠 工廠模式 抽象工廠）
參考博文 侵權必刪 什麼是工廠模式 通過 物件建立 模式繞開new，來避免物件建立 new 過程中所導致的緊耦合 依賴具體類 適用性 使用new建立物件且導致緊耦合的場景。思考 物件導向程式設計要以動態的思維去看待 換句話說，在看 時需要時間概念，發現 在未來的穩定之處和變化之處。一般介面和抽象類是...
設計模式（簡單工廠模式 工廠模式 抽象工廠模式）
當邏輯較為簡單時，可以直接建立對應的類。如下 include using namespace std class class banana class pear intmain 通過此 可以發現，使用者直接與客戶接觸，違背了dip 依賴倒轉 原則，過於麻煩，所以引出簡單工廠模式。include us...
抽象工廠模式 設計模式3之抽象工廠模式
工廠方法模式中工廠只負責同類產品的生產。比如電視機工廠不應該生產汽車。然而現實生活中有很多綜合型的工廠，比如有些電視工廠不僅生產電視機，還會生產與之配套的機頂盒。那麼抽象工廠模式隨之誕生，這種模式將考慮多種型別產品的生產。我們總結下 工廠方法模式只考慮成產同一等級級的產品抽象方法模式考慮生產多等級的...