一、簡單工廠模式

簡單工廠的定義：提供一個創建對象實例的功能，而無須關心其具體實現。被創建實例的類型可以是接口、抽象類，也可以是具體的類

實現汽車接口

public?interface?Car?{String?getName();}

奔馳類

public?class?Benz?implements?Car?{@Overridepublic?String?getName()?{return?"Benz";}
}

寶馬類

public?class?BMW?implements?Car?{@Overridepublic?String?getName()?{return?"BMW";}
}

簡單工廠，既能生產寶馬又能生產奔馳

public?class?SimpleFactory?{public?Car?getCar(String?name){if?(name.equals("BMW")){return?new?BMW();}else?if?(name.equals("benz")){return?new?Benz();}else?{System.out.println("不好意思，這個品牌的汽車生產不了");return?null;}}
}

測試類

public?class?SimpleFactoryTest?{public?static?void?main(String[]?args){SimpleFactory?simpleFactory?=?new?SimpleFactory();Car?car?=?simpleFactory.getCar("BMW");System.out.println(car.getName());}
}

測試結果

BMW

根據簡單工廠的定義，用戶只要產品而不在乎產品如何生產，看起來好像很完美的樣子。但大家想想，這個世界存在什么都生產的工廠嗎？

顯然是不存在的，每一個汽車品牌都有自己的生產工廠，都有自己生產技術。映射到spring框架中，我們有很多很多種的bean需要生產，如果只依靠一個簡單工廠來實現，那么我們得在工廠類中嵌套多少個if..else if啊？

而且我們在代碼中生產一輛汽車只是new一下就出來了，但實際操作中卻不知道需要進行多少操作，加載、注冊等操作都將體現在工廠類中，那么這個類就會變得紊亂，管理起來也很不方便，所以說每個品牌應該有自己的生產類。

因為專一，所以專業嘛，這個時候工廠方法就出現了。

二、工廠方法

工廠接口

//定義一個工廠接口，功能就是生產汽車
public?interface?Factory?{Car?getCar();
}

奔馳工廠

public?class?BenzFactory?implements?Factory?{@Overridepublic?Car?getCar()?{return?new?Benz();}
}

寶馬工廠

public?class?BMWFactory?implements?Factory{@Overridepublic?Car?getCar()?{return?new?BMW();}
}

測試類

public?class?FactoryTest?{public?static?void?main(String[]?args){Factory?bmwFactory?=?new?BMWFactory();System.out.println(bmwFactory.getCar().getName());Factory?benzFactory?=?new?BenzFactory();System.out.println(benzFactory.getCar().getName());}
}

測試結果

BMW
Benz

根據上述代碼可以看出，不同品牌的汽車是由不同的工廠生產的，貌似又是很完美的。但大家看一下測試類，當一個人想要去買一輛寶馬汽車的時候（假設沒有銷售商），那么他就要去找寶馬工廠給他生產一輛，過幾天又想要買一輛奔馳汽車的時候，又得跑到奔馳工廠請人生產，這無疑就增加了用戶的操作復雜性。所以有沒有一種方便用戶操作的方法呢？這個時候抽象工廠模式就出現了。

三、抽象工廠

?抽象工廠

public?abstract?class?AbstractFactory?{protected?abstract?Car?getCar();//這段代碼就是動態配置的功能//固定模式的委派public?Car?getCar(String?name){if("BMW".equalsIgnoreCase(name)){return?new?BmwFactory().getCar();}else?if("Benz".equalsIgnoreCase(name)){return?new?BenzFactory().getCar();}else?if("Audi".equalsIgnoreCase(name)){return?new?AudiFactory().getCar();}else{System.out.println("這個產品產不出來");return?null;}}
}

默認工廠

public?class?DefaultFactory?extends?AbstractFactory?{private?AudiFactory?defaultFactory?=?new?AudiFactory();public?Car?getCar()?{return?defaultFactory.getCar();}}

寶馬工廠

public?class?BMWFactory?extends?AbstractFactory?{@Overridepublic?Car?getCar()?{return?new?BMW();}
}

奔馳工廠

public?class?BenzFactory?extends?AbstractFactory?{@Overridepublic?Car?getCar()?{return?new?Benz();}
}

?測試類

public?class?AbstractFactoryTest?{public?static?void?main(String[]?args)?{????????DefaultFactory?factory?=?new?DefaultFactory();????????System.out.println(factory.getCar("Benz").getName());????????????}
}

測試結果

Benz

根據上述代碼可以看出，用戶需要一輛汽車，只需要去找默認的工廠提出自己的需求（傳入參數），便能得到自己想要產品，而不用根據產品去尋找不同的生產工廠，方便用戶操作。

注：對于設計模式，有些人嗤之以鼻，有些人敬若神明，但我是認可的。

在此我向大家推薦一個架構學習交流圈：830478757? 幫助突破瓶頸 提升思維能力

按我粗淺的理解，設計模式的經典之處，就在于解決了編寫代碼的人和調用代碼的人雙方的痛楚，不同的設計模式也只適用于不同的場景。至于用或者不用，如何使用，那就需要各位看官著重考慮了。

但為了使用而使用是不應該的，細微之處，只有留給大家慢慢品味了。