简单工厂模式是类的创建模式，其专门负责将大量拥有共同接口或者基类的产品类进行实例化。简单工厂模式由工厂类运行时根据传入的参数动态的决定需要实例化的类，这样客户只需要了解产品的基类，解除客户对具体产品类的依赖。简单工厂模式的结构如下图所示
图 1. 简单工厂模式结构图
从图中可以看出，简单工厂模式主要涉及一下三种结构角色
1. 工厂类，其有客户端直接调用，并根据具体的业务逻辑要求创建相应的产品对象实例；
2. 产品基类，所有具体的产品类的基类或者接口，封装所有具体产品共享的行为（和数据）, 客户需要了解产品基类；
3. 具体的产品类，本模式需要创建的实例的类型；
JBPM4.4部署在Tomcat6以上的版本jar包冲突
JBPM流程实例（PV）Process Variables
JBPM中的简单工厂模式
JBPM中对流程引擎的对象的实例化使用了简单工厂模式。具体的模式结构图如下
图 2. JBPM简单工厂结构图
从图中我们可以看到ProcessEngine充当了产品基类的角色，由于流程引擎在JBPM中所处的特殊地位，所以这个接口需要能够获取各种服务和业务中需要使用的一些对象实例等。
具体的产品类是ProcessEngineImpl和SpringProcessEngine类，JBPM的流程引擎可以使用spring作为承载的环境，默认情况下会使用前者，如果我们需要使用spring，只需要在jbpm.cfg.xml中引入jbpm.tx.spring.cfg.xml即可。
工厂类的角色是由ConfigurationImpl来实现的，其根据配置文件中是否启用spring来实例化具体的流程引擎对象。
其实SpringProcessEngine本身也是一个精简版的简单工厂模式，其自己负责实例化自己，其同时担当了工厂和具体产品的角色。具体的类图结构如下
图 3. SpringProcessEngine精简版简单工厂设计模式
简单工厂模式的优劣
该模式的核心是工厂类，其负责必要的逻辑判断（反射的话可以不需要），决定最终创建哪一个产品类的实例。客户是不负责产品类的实例化，而是仅仅使用返回的产品，实现了两者间的职责分离。
该模式中，工厂类负责所有具体产品类的创建逻辑，所以其就对所有的产品类形成了强烈的依赖，如果产品类很多，可能对工厂类的修改就会影响到整个系统。
当我们扩展了新的产品类的时候，需要修改工厂类，违反了开闭原则。