抽象工廠模式的意圖是提供乙個建立一系列相關或相互依賴物件的介面，而無需指定它們具體的類。如圖所示，在抽象工廠模式中，客戶程式只知道抽象的工廠和抽象的產品，在這種情況下程式設計，真正做到了針對介面程式設計而不是針對實現程式設計。
抽象工廠模式是23個設計模式中的第乙個，應用不可謂不廣泛，所以在jdk的原始碼中也有很多應用抽象工廠的地方，在這裡我舉的例子來自calendar類。
calendar類的getinstance()方法就是抽象工廠應用的絕佳例子，calendar（相當於抽象工廠）根據client傳入的不同引數例項化不同的類（即得到不同的產品），實現了抽象工廠模式。我就不廢話了，直接上**：
public static calendar getinstance(timezone zone,
locale alocale)
private static calendar createcalendar(timezone zone,
locale alocale)
else if ("jp".equals(alocale.getvariant())
&& "jp".equals(alocale.getcountry())
&& "ja".equals(alocale.getlanguage()))
// else create the default calendar
return new gregoriancalendar(zone, alocale);
}
它跟書本上的教課書式的抽象工廠模式還是有區別的：很明顯，這裡的抽象工廠（calendar類）和抽象產品（calendar類）是同乙個類，但我依然認為calendar是乙個抽象工廠的實現，因為，做設計變通是必須的，盡信書，則不如無書！
抽象工廠模式在23個經典設計模式中算是比較簡單的乙個，實現它並不複雜，但是與關注它的實現相比，我更關注它的應用。抽象工廠模式適用於設計中強調一系列相關產品物件的情況，在這種情況下使用抽象工廠模式能夠分離介面與實現，使我們能夠針對介面程式設計而非針對實現，這樣帶來乙個好處：使我們更方便的交換產品系列（只需更換一次具體工廠的實現即可）。
同時，抽象工廠模式也有乙個致命的缺點：難以支援新種類的產品，從uml圖中可以看出，abstractfactory支援的產品種類是寫死的，當要增加乙個新產品時，整個abstractfactory繼承體系都必須重構，這是十分麻煩的！幸虧，這種災難性的情況並非不可避免，一種更靈活的設計是給建立物件的操作增加乙個引數，該引數指定了將被建立物件的種類，calendar類就是用了這種方法，如果它想增加乙個產品，只需在createcalendar方法中多加乙個else if語句即可，靈活而方便！
設計模式之簡單工廠 工廠方法模式 抽象工廠模式
這裡講三種模式放在一起說明，是因為三種模式關聯性很強 抽象工廠模式簡單化以後就是工廠方法模式，工廠方法模式再簡單化就是簡單工廠模式 簡單工廠模式並沒有被列入到gof的設計模式中 public class factory 簡單工廠類，實現建立產品物件 class factory return prod...
設計模式之工廠 抽象工廠
一 應用場景 工廠模式應用非常廣泛，意在抽象出一層專職管理物件產生以及物件間的關係，讓我們能夠專注於業務開發 1.不用去寫許許多多的new方法，替換實現類還得挨個修改。2.類中不涉及實現類，物件間只存在介面級別的耦合，客戶端呼叫注入實現類即可。由於工廠模式變種非常多，這裡只講一下常用的簡單工廠和抽象...
抽象工廠模式 設計模式3之抽象工廠模式
工廠方法模式中工廠只負責同類產品的生產。比如電視機工廠不應該生產汽車。然而現實生活中有很多綜合型的工廠，比如有些電視工廠不僅生產電視機，還會生產與之配套的機頂盒。那麼抽象工廠模式隨之誕生，這種模式將考慮多種型別產品的生產。我們總結下 工廠方法模式只考慮成產同一等級級的產品抽象方法模式考慮生產多等級的...