Java设计模式：工厂模式

假设一个场景，一个抽象类，派生出很多的子类，根据不同的需求，需要new出不同的子类，为了方便统一管理这些子类的创建，就可以使用工厂模式

简单工厂模式

在简单工厂中代码是这样的，根据你传入的参数，给你创建对应的实现类，这就是简单工厂模式

 public IComputer getService(String type) {     IComputer service = null;     if ("A".equals(type)) {  service = new HuaWeiIComputer();     }     if ("B".equals(type)) {  service = new AppleIComputer();     }     //生产电脑     service.method();     return service; }

对实现类进行了统一管理，但是如果需要添加新的实现类，就必须位维护工厂类对象代码，违背了开闭原则

在Calendar中就使用了简单工厂模式

 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;  }     } }

工厂方法模式

为了解决简单工厂的弊端，提出了工厂方法模式，把工厂也作为一个接口，对每一种产品，提供对应的工厂对象，这样添加工厂就可以实现业务的拓展
调用方通过new不同的工厂实现来创建不同的对象

增加或者删除业务任然需要修改代码，添加新的类即可
但是这就是只要增加一个产品，就要新建一个类，会产生类爆炸

抽象工厂

前边的两种工厂都考虑的是一个工厂是生产一种产品，抽象工厂是为了同时生产多种产品

抽象的接口工厂提供生产多种产品的方法，具体工厂完成各个方法的实现
商品根据抽象商品类型进行派生，工厂根据抽象工厂需要创建哪些商品，都要提供实现

在Spring中，所有工厂都是BeanFactory的子类，BeanFactory根据不同的策略调用getBean，获取不同的对象。

优点：保证所有产品都来自同一商品族
缺点：工厂需要新增一个新的产品时，所有的实现工厂类都必须进行修改！