一、設計模式的分類
總的來說，設計模式可以分為三大類：創建型模式、結構型模式、行為型模式，具體如下圖：
二、工廠模式
工廠模式分為簡單工廠模式、工廠方法模式和抽象工廠模式。其中簡單工廠模式並不屬於23種設計模式，但並不影響它的廣泛使用。在JDK的源碼當中，就存在着許多這樣的例子。
2.1 簡單工廠模式
我們先來看一段代碼：
public static void main(String[] args) {
// 日歷類
Calendar calendar = Calendar.getInstance();
SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
System.out.println("當前時間為：" + simpleDateFormat.format(calendar.getTime()));
calendar.add(Calendar.HOUR,2);
System.out.println("當前時間加了兩個小時后,時間是: " + simpleDateFormat.format(calendar.getTime()));
}
這段代碼，大家應該比較熟悉，通過對Calendar的一系列操作，打印出當前時間和當前時間加兩個小時后的時間，這里我們來看看結果：
結果正和我們想象的一樣，兩次打印出來的時間相隔兩個小時。但我們今天的重點是Calendar calendar = Calendar.getInstance()這段代碼，通過getInstance()方法拿到了Calendar 類的實例。來看看具體的源代碼：
public static Calendar getInstance(){
return createCalendar(TimeZone.getDefault(), Locale.getDefault(Locale.Category.FORMAT));
}
// 代碼不全，有興趣的朋友可以去看JDK源碼
private static Calendar createCalendar(TimeZone zone, Locale aLocale){
// 中間的代碼省略.....
Calendar cal = null;
if (aLocale.hasExtensions()) {
String caltype = aLocale.getUnicodeLocaleType("ca");
if (caltype != null) {
switch (caltype) {
case "buddhist":
cal = new BuddhistCalendar(zone, aLocale);
break;
case "japanese":
cal = new JapaneseImperialCalendar(zone, aLocale);
break;
case "gregory":
cal = new GregorianCalendar(zone, aLocale);
break;
}
}
}
// 中間的代碼省略.....
return cal;
}
可以看出，getInstance()方法里面調用了createCalendar()方法來得到Calendar類的實例，最后返回給調用者。而createCalendar()方法中通過switch(){case}的判斷來返回所對應的Calendar類的實例，這其實就是簡單工廠模式的一種應用。
看完簡單工廠模式在JDK中的應用之后，我們來設計一下自己的例子：
小明家新開了一家小工廠，接了一單生意，幫助海爾（Haier）集團生產冰箱，並需要設計相應的方案。小明本身也是程序員出身，思考一會后就寫出了下面的代碼：
/**
* 冰箱
*/
public interface IFridge {
// 生產冰箱
public void createFridge();
}
/**
* 海爾
*/
public class Haier implements IFridge {
@Override
public void createFridge() {
System.out.println("生產海爾冰箱...");
}
}
客戶端調用代碼：
public static void main(String[] args) {
IFridge iFridge = new Haier();
iFridge.createFridge();
}
看上面的代碼，父類IFridge類指向子類Haier類的引用，應用層需要依賴於Haier。如果業務擴展，后續增加格力（Gree）甚至更多，那么客戶端這里的代碼會越來越臃腫。所以，我們要想辦法將這種依賴減弱，將創建IFridge對象的細節隱藏掉。我們用簡單工廠模式優化一下：
創建Gree格力類
/**
* 格力
*/
public class Gree implements IFridge {
@Override
public void createFridge() {
System.out.println("生產格力冰箱...");
}
}
創建FridgeFactory工廠類
/**
* 冰箱工廠
*/
public class FridgeFactory {
// 創建對應的 IFridge 實例
public static IFridge createFridge(String name){
if ("haier".equals(name)){
return new Haier();
} else if ("gree".equals(name)){
return new Gree();
}
return null;
}
}
修改客戶端調用的代碼：
public static void main(String[] args) {
// 海爾
IFridge haier = FridgeFactory.createFridge("haier");
haier.createFridge();
// 格力
IFridge gree = FridgeFactory.createFridge("gree");
gree.createFridge();
}
這樣來看，雖然代碼多了，但維護起來以及擴展起來就方便很多，來看一看類圖：
當然，上面的FridgeFactory代碼中依舊有些問題，如果我們需要增加生產美的（Midea）冰箱，那么我們就需要去修改createFridge()方法的代碼，顯然違背了開閉原則，我們來改造一下：
修改FridgeFactory工廠類
/**
* 冰箱工廠
*/
public class FridgeFactory {
// 創建對應的 IFridge 實例
public static IFridge createFridge(String className){
try {
if (null != className && !"".equals(className)){
// 反射
return (IFridge)Class.forName(className).newInstance();
}
}catch (Exception e){
e.printStackTrace();
}
return null;
}
}
修改客戶端調用的代碼
public static void main(String[] args) {
// com.xxx.Haier 換成 自己 項目中 Haier 所在的位置 海爾
IFridge haier = FridgeFactory.createFridge("com.xxx.Haier");
haier.createFridge();
// com.xxx.Gree 換成 自己 項目中 Gree 所在的位置 格力
IFridge gree = FridgeFactory.createFridge("com.xxx.Gree");
gree.createFridge();
}
優化之后，我們再也不需要隨着業務的提升而去修改FridgeFactory類中的代碼了。但是依舊有一個問題，createFridge()方法中的參數是字符串，如果有人亂填怎么辦，那不就報錯了，所以再來優化一下：
修改FridgeFactory工廠類
/**
* 冰箱工廠
*/
public class FridgeFactory {
// 創建對應的 IFridge 實例
public static IFridge createFridge(Class<? extends IFridge> clazz){
try {
if (clazz != null){
return clazz.newInstance();
}
}catch (Exception e){
e.printStackTrace();
}
return null;
}
}
修改客戶端調用的代碼
public static void main(String[] args) {
// 海爾
FridgeFactory.createFridge(Haier.class).createFridge();
// 格力
FridgeFactory.createFridge(Gree.class).createFridge();
}
再來看一下類圖：
簡單工廠模式雖然好用，但也有它的局限性：工廠類的職責過重，不利於擴展更為復雜產品結構。
2.2 工廠方法模式
定義一個創建對象的接口，但讓實現這個接口的類來決定實例化哪個類，工廠方法讓類的實例化推遲到子類中進行。
在工廠方法模式中用戶只需要關心所需產品對應的工廠，無須關心創建細節，而且加入新的產品符合開閉原則。
隨着小明家新工廠的生意火爆，各類的訂單都紛涌而至，各個牌子的廠家都想讓小明家的工廠生產冰箱，小明無奈只能開了分工廠，並根據客戶的品牌名給工廠取了對應的名字，其中海爾工廠生產海爾的冰箱，格力工廠生產格力的冰箱，美的工廠生產美的的冰箱。用代碼演化就是下面這般：
IFridgeFactory類接口
public interface IFridgeFactory {
public IFridge createIFridge();
}
海爾
// 海爾 工廠
public class HaierFactory implements IFridgeFactory {
@Override
public IFridge createIFridge() {
return new Haier();
}
}
格力
// 格力 工廠
public class GreeFactory implements IFridgeFactory {
@Override
public IFridge createIFridge() {
return new Gree();
}
}
美的
/**
* 美的
*/
public class Midea implements IFridge {
@Override
public void createFridge() {
System.out.println("生產美的冰箱...");
}
}
// 美的
public class MideaFactory implements IFridgeFactory {
@Override
public IFridge createIFridge() {
return new Midea();
}
}
客戶端調用：
public static void main(String[] args) {
// 格力
new GreeFactory().createIFridge().createFridge();
// 海爾
new HaierFactory().createIFridge().createFridge();
// 美的
new MideaFactory().createIFridge().createFridge();
}
這里其實就是細化了工廠，將業務拆分，利用了設計模式原則中的單一職責原則，讓每個品牌對應工廠只干一件事，不去摻和其他品牌的事情。來看一看類圖：
工廠方法模式適用於一下場景：
- 創建對象需要大量重復的代碼
- 客戶端（應用層）不依賴於產品類實例如何被創建、實現等細節
- 一個類通過其子類來指定創建哪個對象
工廠方法模式也有缺點：
- 類的個數容易過多，增加復雜度
- 增加了系統的抽象性和理解難度
2.3 抽象工廠模式
定義：提供一個創建一系列相關或者相互依賴對象的接口，無需指定他們具體的類。
這個定義讀起來相當的拗口，很抽象，不好理解。還是和上面的例子結合來說明：
在生產完一批冰箱並上市售賣之后，美的、格力、海爾等公司非常滿意，慢慢的將自己家的空調、熱水器也交給小明家的工廠去生產了。小明為此在對應的品牌工廠有開辟了對應的生產設備的空間（這里為了大家看的方便，我將所有的代碼都放上去）：
冰箱、空調、熱水器接口
// 冰箱
public interface IFridge {
// 生產冰箱
public void createFridge();
}
// 空調
public interface IAirConditioner {
// 生產空調
public void createAirConditioner();
}
// 熱水器
public interface IWaterHeater {
// 生產熱水器
public void createWaterHeater();
}
海爾
/**
* 海爾 冰箱
*/
public class HaierFridge implements IFridge{
@Override
public void createFridge() {
System.out.println("生產海爾冰箱...");
}
}
// 海爾 空調
public class HaierAirConditioner implements IAirConditioner {
@Override
public void createAirConditioner() {
System.out.println("生產海爾空調...");
}
}
// 海爾熱水器
public class HaierWaterHeater implements IWaterHeater {
@Override
public void createWaterHeater() {
System.out.println("生產海爾熱水器...");
}
}
格力
/**
* 格力 冰箱
*/
public class GreeFridge implements IFridge {
@Override
public void createFridge() {
System.out.println("生產格力冰箱...");
}
}
// 格力 空調
public class GreeAirConditioner implements IAirConditioner {
@Override
public void createAirConditioner() {
System.out.println("生產格力空調...");
}
}
// 格力熱水器
public class GreeWaterHeater implements IWaterHeater {
@Override
public void createWaterHeater() {
System.out.println("生產格力熱水器...");
}
}
美的
/**
* 美的 冰箱
*/
public class MideaFridge implements IFridge{
@Override
public void createFridge() {
System.out.println("生產美的冰箱...");
}
}
// 美的 空調
public class MideaAirConditioner implements IAirConditioner {
@Override
public void createAirConditioner() {
System.out.println("生產美的空調...");
}
}
// 美的熱水器
public class MideaWaterHeater implements IWaterHeater {
@Override
public void createWaterHeater() {
System.out.println("生產美的熱水器...");
}
}
工廠接口
public interface IFactory {
// 冰箱
public IFridge createIFridge();
// 空調
public IAirConditioner createIConditioner();
// 熱水器
public IWaterHeater createIWaterHeater();
}
海爾工廠
// 海爾 工廠
public class HaierFactory implements IFactory {
// 冰箱
@Override
public IFridge createIFridge() {
return new HaierFridge();
}
// 空調
@Override
public IAirConditioner createIConditioner() {
return new HaierAirConditioner();
}
// 熱水器
@Override
public IWaterHeater createIWaterHeater() {
return new HaierWaterHeater();
}
}
格力工廠
// 格力
public class GreeFactory implements IFactory {
// 冰箱
@Override
public IFridge createIFridge() {
return new GreeFridge();
}
// 空調
@Override
public IAirConditioner createIConditioner() {
return new GreeAirConditioner();
}
// 熱水器
@Override
public IWaterHeater createIWaterHeater() {
return new GreeWaterHeater();
}
}
美的工廠
// 美的
public class MideaFactory implements IFactory {
// 冰箱
@Override
public IFridge createIFridge() {
return new MideaFridge();
}
// 空調
@Override
public IAirConditioner createIConditioner() {
return new MideaAirConditioner();
}
// 熱水器
@Override
public IWaterHeater createIWaterHeater() {
return new MideaWaterHeater();
}
}
客戶端調用
public static void main(String[] args) {
// 海爾工廠
HaierFactory haierFactory = new HaierFactory();
haierFactory.createIFridge().createFridge();
haierFactory.createIConditioner().createAirConditioner();
haierFactory.createIWaterHeater().createWaterHeater();
// 格力工廠
GreeFactory greeFactory = new GreeFactory();
greeFactory.createIFridge().createFridge();
greeFactory.createIConditioner().createAirConditioner();
greeFactory.createIWaterHeater().createWaterHeater();
// 美的工廠
MideaFactory mideaFactory = new MideaFactory();
mideaFactory.createIFridge().createFridge();
mideaFactory.createIConditioner().createAirConditioner();
mideaFactory.createIWaterHeater().createWaterHeater();
}
類圖
從上面一大堆的代碼，尤其是類圖，我們可以很明顯的感覺到，抽象工廠可以完美清晰的描述海爾、格力、美的三個品牌的冰箱、空調、熱水器的龐大體系。但也正因為如此，抽象工廠給我們的視覺沖擊有些大，能很明顯的感覺到系統的復雜性、抽象性以及系統的極難擴展性；並且這里還隱藏着一個違背開閉原則的問題：
在工廠接口
IFactory類中，如果在日后的產品升級當中，需要增加生產洗衣機的業務，那這里修改之后，所有實現IFactory接口的類都需要變動，很大程度增加了系統的不穩定性。
也正因為如此，在實際的業務開發中，我們不應該有着強烈的強迫症和潔癖，認為一個系統的結構設計必須要完美的符合各種原則。要結合實際的業務去思考，如果系統結構的等級更新不頻繁的話，不遵守某些原則也是有必要性的，畢竟所有的技術都是為業務而服務的。