1、簡單工廠模式spring
簡單工廠的定義:提供一個建立對象實例的功能,而無須關心其具體實現。被建立實例的類型能夠是接口、抽象類,也能夠是具體的類設計模式
實現汽車接口框架
public interface Car { String getName(); }
奔馳類ide
public class Benz implements Car { @Override public String getName() { return "Benz"; } }
寶馬類測試
public class BMW implements Car { @Override public String getName() { return "BMW"; } }
簡單工廠,既能生產寶馬又能生產奔馳spa
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()); } }
測試結果code
BMW
根據簡單工廠的定義,用戶只要產品而不在意產品如何生產,看起來好像很完美的樣子。但你們想一想,這個世界存在什麼都生產的工廠嗎?對象
顯然是不存在的,每個汽車品牌都有本身的生產工廠,都有本身生產技術。映射到spring框架中,咱們有不少不少種的bean須要生產,若是隻依靠一個簡單工廠來實現,那麼咱們得在工廠類中嵌套多少個if..else if啊?blog
並且咱們在代碼中生產一輛汽車只是new一下就出來了,但實際操做中殊不知道須要進行多少操做,加載、註冊等操做都將體如今工廠類中,那麼這個類就會變得紊亂,管理起來也很不方便,因此說每一個品牌應該有本身的生產類。
由於專注,因此專業嘛,這個時候工廠方法就出現了。
2、工廠方法
工廠接口
//定義一個工廠接口,功能就是生產汽車 public interface Factory { Car getCar(); }
奔馳工廠
public class BenzFactory implements Factory { @Override public Car getCar() { return new Benz(); } }
寶馬工廠
public class BMWFactory implements Factory{ @Override public 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
根據上述代碼能夠看出,不一樣品牌的汽車是由不一樣的工廠生產的,貌似又是很完美的。但你們看一下測試類,當一我的想要去買一輛寶馬汽車的時候(假設沒有銷售商),那麼他就要去找寶馬工廠給他生產一輛,過幾天又想要買一輛奔馳汽車的時候,又得跑到奔馳工廠請人生產,這無疑就增長了用戶的操做複雜性。因此有沒有一種方便用戶操做的方法呢?這個時候抽象工廠模式就出現了。
3、抽象工廠
抽象工廠
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 { @Override public Car getCar() { return new BMW(); } }
奔馳工廠
public class BenzFactory extends AbstractFactory { @Override public 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
根據上述代碼能夠看出,用戶須要一輛汽車,只須要去找默認的工廠提出本身的需求(傳入參數),便能獲得本身想要產品,而不用根據產品去尋找不一樣的生產工廠,方便用戶操做。
注:對於設計模式,有些人嗤之以鼻,有些人敬若神明,但我是承認的。
按我粗淺的理解,設計模式的經典之處,就在於解決了編寫代碼的人和調用代碼的人雙方的痛楚,不一樣的設計模式也只適用於不一樣的場景。至於用或者不用,如何使用,那就須要各位看官着重考慮了。
但爲了使用而使用是不該該的,細微之處,只有留給你們慢慢品味了。