工厂方法模式有很多扩展，而且与其他模式结合使用威力更大，下面将介绍4种扩展。
1. 缩小为简单工厂模式
我们这样考虑一个问题：一个模块仅需要一个工厂类，没有必要把它产生出来，使用静态的方法就可以了，根据这一要求，我们把上例中的AbstarctHumanFactory修改一下，类图如图8-3所示。
图8-3 简单工厂模式类图
我们在类图中去掉了AbstractHumanFactory抽象类，同时把createHuman方法设置为静态类型，简化了类的创建过程，变更的源码仅仅是HumanFactory和NvWa类，HumanFactory如代码清单8-13所示。
代码清单8-13 简单工厂模式中的工厂类
public class HumanFactory { public static <T extends Human> T createHuman(Class<T> c){ //定义一个生产出的人种 Human human=null; try { //产生一个人种 human = (Human)Class.forName(c.getName).newInstance; } catch (Exception e) { System.out.println(/"人种生成错误！/"); } return (T)human; }} HumanFactory类仅有两个地方发生变化：去掉继承抽象类，并在createHuman前增加static关键字；工厂类发生变化，也同时引起了调用者NvWa的变化，如代码清单8-14示。
代码清单8-14 简单工厂模式中的场景类
public class NvWa { public static void main(String args) { //女娲第一次造人，火候不足，于是白色人种产生了 System.out.println(/"--造出的第一批人是白色人种--/"); Human whiteHuman = HumanFactory.createHuman(WhiteHuman.class); whiteHuman.getColor; whiteHuman.talk; //女娲第二次造人，火候过足，于是黑色人种产生了 System.out.println(/"n--造出的第二批人是黑色人种--/"); Human blackHuman = HumanFactory.createHuman(BlackHuman.class); blackHuman.getColor; blackHuman.talk; //第三次造人，火候刚刚好，于是黄色人种产生了 System.out.println(/"n--造出的第三批人是黄色人种--/"); Human yellowHuman = HumanFactory.createHuman(YellowHuman.class); yellowHuman.getColor; yellowHuman.talk; }} 运行结果没有发生变化，但是我们的类图变简单了，而且调用者也比较简单，该模式是工厂方法模式的弱化，因为简单，所以称为简单工厂模式（Simple Factory Pattern），也叫做静态工厂模式。在实际项目中，采用该方法的案例还是比较多的，其缺点是工厂类的扩展比较困难，不符合开闭原则，但它仍然是一个非常实用的设计模式。
2. 升级为多个工厂类
当我们在做一个比较复杂的项目时，经常会遇到初始化一个对象很耗费精力的情况，所有的产品类都放到一个工厂方法中进行初始化会使代码结构不清晰。例如，一个产品类有5个具体实现，每个实现类的初始化（不仅仅是new，初始化包括new一个对象，并对对象设置一定的初始值）方法都不相同，如果写在一个工厂方法中，势必会导致该方法巨大无比，那该怎么办？
考虑到需要结构清晰，我们就为每个产品定义一个创造者，然后由调用者自己去选择与哪个工厂方法关联。我们还是以女娲造人为例，每个人种都有一个固定的八卦炉，分别造出黑色人种、白色人种、黄色人种，修改后的类图如图8-4所示。
图8-4 多个工厂类的类图
每个人种（具体的产品类）都对应了一个创建者，每个创建者都独立负责创建对应的产品对象，非常符合单一职责原则，按照这种模式我们来看看代码变化。
多工厂模式的抽象工厂类如代码清单8-15所示。
代码清单8-15 多工厂模式的抽象工厂类
public abstract class AbstractHumanFactory { public abstract Human createHuman;} 注意 抽象方法中已经不再需要传递相关参数了，因为每一个具体的工厂都已经非常明确自己的职责：创建自己负责的产品类对象。
黑色人种的创建工厂如代码清单8-16所示。
代码清单8-16 黑色人种的创建工厂实现
public class BlackHumanFactory extends AbstractHumanFactory { public Human createHuman { return new BlackHuman; }} 黄色人种的创建工厂如代码清单8-17所示。
代码清单8-17 黄色人种的创建类
public class YellowHumanFactory extends AbstractHumanFactory { public Human createHuman { return new YellowHuman; }} 白色人种的创建工厂如代码清单8-18所示。
代码清单8-18 白色人种的创建类
public class whiteHumanFactory extends AbstractHumanFactory { public Human createHuman { return new WhiteHuman; }} 三个具体的创建工厂都非常简单，但是，如果一个系统比较复杂时工厂类也会相应地变复杂。场景类NvWa修改后的代码如代码清单8-19所示。
代码清单8-19 场景类NvWa
public class NvWa { public static void main(String args) { //女娲第一次造人，火候不足，于是白色人种产生了 System.out.println(/"--造出的第一批人是白色人种--/"); Human whiteHuman = (new WhiteHumanFactory).createHuman; whiteHuman.getColor; whiteHuman.talk; //女娲第二次造人，火候过足，于是黑色人种产生了 System.out.println(/"n--造出的第二批人是黑色人种--/"); Human blackHuman = (new BlackHumanFactory).createHuman; blackHuman.getColor; blackHuman.talk; //第三次造人，火候刚刚好，于是黄色人种产生了 System.out.println(/"n--造出的第三批人是黄色人种--/"); Human yellowHuman = (new YellowHumanFactory).createHuman; yellowHuman.getColor; yellowHuman.talk; }} 运行结果还是相同。我们回顾一下，每一个产品类都对应了一个创建类，好处就是创建类的职责清晰，而且结构简单，但是给可扩展性和可维护性带来了一定的影响。为什么这么说呢？如果要扩展一个产品类，就需要建立一个相应的工厂类，这样就增加了扩展的难度。因为工厂类和产品类的数量相同，维护时需要考虑两个对象之间的关系。
当然，在复杂的应用中一般采用多工厂的方法，然后再增加一个协调类，避免调用者与各个子工厂交流，协调类的作用是封装子工厂类，对高层模块提供统一的访问接口。
3. 替代单例模式
第7章讲述了单例模式以及扩展出的多例模式，并且指出了单例和多例的一些缺点，我们是不是可以采用工厂方法模式实现单例模式的功能呢？单例模式的核心要求就是在内存中只有一个对象，通过工厂方法模式也可以只在内存中生产一个对象，类图如图8-5所示。
图8-5 工厂方法模式替代单例模式类图
非常简单的类图，Singleton定义了一个private的无参构造函数，目的是不允许通过new的方式创建一个对象，如代码清单8-20所示。
代码清单8-20 单例类
public class Singleton { //不允许通过new产生一个对象 private Singleton{ } public void doSomething{ //业务处理 }} Singleton保证不能通过正常的渠道建立一个对象，那SingletonFactory如何建立一个单例对象呢？答案是通过反射方式创建，如代码清单8-21所示。
代码清单8-21 负责生成单例的工厂类
public class SingletonFactory { private static Singleton singleton; static{ try { Class cl= Class.forName(Singleton.class.getName); //获得无参构造 Constructor constructor=cl.getDeclaredConstructor; //设置无参构造是可访问的 constructor.setAccessible(true); //产生一个实例对象 singleton = (Singleton)constructor.newInstance; } catch (Exception e) { //异常处理 } } public static Singleton getSingleton{ return singleton; }} 通过获得类构造器，然后设置访问权限，生成一个对象，然后提供外部访问，保证内存中的对象唯一。当然，其他类也可以通过反射的方式建立一个单例对象，确实如此，但是一个项目或团队是有章程和规范的，何况已经提供了一个获得单例对象的方法，为什么还要重新创建一个新对象呢？除非是有人作恶。
以上通过工厂方法模式创建了一个单例对象，该框架可以继续扩展，在一个项目中可以产生一个单例构造器，所有需要产生单例的类都遵循一定的规则（构造方法是private），然后通过扩展该框架，只要输入一个类型就可以获得唯一的一个实例。
4. 延迟初始化
何为延迟初始化（Lazy initialization）？一个对象被消费完毕后，并不立刻释放，工厂类保持其初始状态，等待再次被使用。延迟初始化是工厂方法模式的一个扩展应用，其通用类图如图8-6所示。
图8-6 延迟初始化的通用类图
ProductFactory负责产品类对象的创建工作，并且通过prMap变量产生一个缓存，对需要再次被重用的对象保留，Product和ConcreteProduct是一个示例代码，请参考代码清单8-8和代码清单8-9。ProductFactory如代码清单8-22所示。
代码清单8-22 延迟加载的工厂类
public class ProductFactory { private static final Map<String,Product> prMap = new HashMap; public static synchronized Product createProduct(String type) throws Exception{ Product product =null;//如果Map中已经有这个对象 if(prMap.containsKey(type)){ product = prMap.get(type); }else{ if(type.equals(/"Product1/")){ product = new ConcreteProduct1; }else{ product = new ConcreteProduct2; } //同时把对象放到缓存容器中 prMap.put(type,product); } return product; }} 代码还比较简单，通过定义一个Map容器，容纳所有产生的对象，如果在Map容器中已经有的对象，则直接取出返回；如果没有，则根据需要的类型产生一个对象并放入到Map容器中，以方便下次调用。
延迟加载框架是可以扩展的，例如限制某一个产品类的最大实例化数量，可以通过判断Map中已有的对象数量来实现，这样的处理是非常有意义的，例如JDBC连接数据库，都会要求设置一个MaxConnections最大连接数量，该数量就是内存中最大实例化的数量。
延迟加载还可以用在对象初始化比较复杂的情况下，例如硬件访问，涉及多方面的交互，则可以通过延迟加载降低对象的产生和销毁带来的复杂性。