Java设计模式：工厂模式

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，获取不同的对象。

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

模式拓展

使用简单工厂+配置文件解除耦合，将类名写进配置文件中，在工厂类中提供方法为根据类名来创建对应的对象
Client调用时直接传入配置文件中的key，通过工厂内部的反射就可以获取到相对应的类

JDK源码中的工厂模式

Collection.Iterator 迭代器就是用了工厂模式
Collection接口时抽象工厂类，ArrayList是具体的工厂类，Iterator是抽象商品类，ArrayList中的Iter内部类是具体的商品类，在具体工厂类中iterator（）方法创建具体的商品类