一、簡單工廠模式
簡單工廠的定義：提供一個創建對象實例的功能，而無須關心其具體實現。被創建實例的類型可以是接口、抽象類，也可以是具體的類
實現汽車接口
public interfaceCar {
String getName();
}
奔馳類
public class Benz implementsCar {
@OverridepublicString getName() {return "Benz";
}
}
寶馬類
public class BMW implementsCar {
@OverridepublicString getName() {return "BMW";
}
}
簡單工廠，既能生產寶馬又能生產奔馳
public classSimpleFactory {publicCar getCar(String name){if (name.equals("BMW")){return newBMW();
}else if (name.equals("benz")){return newBenz();
}else{
System.out.println("不好意思，這個品牌的汽車生產不了");return null;
}
}
}
測試類
public classSimpleFactoryTest {public static voidmain(String[] args){
SimpleFactory simpleFactory= newSimpleFactory();
Car car= simpleFactory.getCar("BMW");
System.out.println(car.getName());
}
}
測試結果
BMW
根據簡單工廠的定義，用戶只要產品而不在乎產品如何生產，看起來好像很完美的樣子。但大家想想，這個世界存在什么都生產的工廠嗎？
顯然是不存在的，每一個汽車品牌都有自己的生產工廠，都有自己生產技術。映射到spring框架中，我們有很多很多種的bean需要生產，如果只依靠一個簡單工廠來實現，那么我們得在工廠類中嵌套多少個if..else if啊？
而且我們在代碼中生產一輛汽車只是new一下就出來了，但實際操作中卻不知道需要進行多少操作，加載、注冊等操作都將體現在工廠類中，那么這個類就會變得紊亂，管理起來也很不方便，所以說每個品牌應該有自己的生產類。
因為專一，所以專業嘛，這個時候工廠方法就出現了。
二、工廠方法
工廠接口
//定義一個工廠接口，功能就是生產汽車
public interfaceFactory {
Car getCar();
}
奔馳工廠
public class BenzFactory implementsFactory {
@OverridepublicCar getCar() {return newBenz();
}
}
寶馬工廠
public class BMWFactory implementsFactory{
@OverridepublicCar getCar() {return newBMW();
}
}
測試類
public classFactoryTest {public static voidmain(String[] args){
Factory bmwFactory= newBMWFactory();
System.out.println(bmwFactory.getCar().getName());
Factory benzFactory= newBenzFactory();
System.out.println(benzFactory.getCar().getName());
}
}
測試結果
BMW
Benz
根據上述代碼可以看出，不同品牌的汽車是由不同的工廠生產的，貌似又是很完美的。但大家看一下測試類，當一個人想要去買一輛寶馬汽車的時候(假設沒有銷售商)，那么他就要去找寶馬工廠給他生產一輛，過幾天又想要買一輛奔馳汽車的時候，又得跑到奔馳工廠請人生產，這無疑就增加了用戶的操作復雜性。所以有沒有一種方便用戶操作的方法呢？這個時候抽象工廠模式就出現了。
三、抽象工廠
抽象工廠
public abstract classAbstractFactory {protected abstractCar getCar();//這段代碼就是動態配置的功能//固定模式的委派
publicCar getCar(String name){if("BMW".equalsIgnoreCase(name)){return newBmwFactory().getCar();
}else if("Benz".equalsIgnoreCase(name)){return newBenzFactory().getCar();
}else if("Audi".equalsIgnoreCase(name)){return newAudiFactory().getCar();
}else{
System.out.println("這個產品產不出來");return null;
}
}
}
默認工廠
public class DefaultFactory extendsAbstractFactory {private AudiFactory defaultFactory = newAudiFactory();publicCar getCar() {returndefaultFactory.getCar();
}
}
寶馬工廠
public class BMWFactory extendsAbstractFactory {
@OverridepublicCar getCar() {return newBMW();
}
}
奔馳工廠
public class BenzFactory extendsAbstractFactory {
@OverridepublicCar getCar() {return newBenz();
}
}
測試類
public classAbstractFactoryTest {public static voidmain(String[] args) {
DefaultFactory factory= newDefaultFactory();
System.out.println(factory.getCar("Benz").getName());
}
}
測試結果
Benz
根據上述代碼可以看出，用戶需要一輛汽車，只需要去找默認的工廠提出自己的需求(傳入參數)，便能得到自己想要產品，而不用根據產品去尋找不同的生產工廠，方便用戶操作。
注：對于設計模式，有些人嗤之以鼻，有些人敬若神明，但我是認可的。
按我粗淺的理解，設計模式的經典之處，就在于解決了編寫代碼的人和調用代碼的人雙方的痛楚，不同的設計模式也只適用于不同的場景。至于用或者不用，如何使用，那就需要各位看官著重考慮了。
但為了使用而使用是不應該的，細微之處，只有留給大家慢慢品味了。
)
