工厂模式【常用】
- 一般情况下,工厂模式分为三种更加细分的类型:简单工厂、工厂方法和抽象工厂。不过,在 GoF 的《设计模式》一书中,它将简单工厂模式看作是工厂方法模式的一种特例,所以工厂模式只被分成了工厂方法和抽象工厂两类。实际上,前面一种分类方法更加常见,所以,在今天的讲解中,我们沿用第一种分类方法。
- 在这三种细分的工厂模式中,简单工厂、工厂方法原理比较简单,在实际的项目中也比较常用。而抽象工厂的原理稍微复杂点,在实际的项目中相对也不常用。所以,我们今天讲解的重点是前两种工厂模式。对于抽象工厂,稍微了解一下即可。
- 除此之外,我们讲解的重点也不是原理和实现,因为这些都很简单,重点还是带你搞清楚应用场景:什么时候该用工厂模式?相对于直接 new 来创建对象,用工厂模式来创建究竟有什么好处呢?
简单工厂【常用】
定义:通过专门定义一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类。
首先,我们来看,什么是简单工厂模式。我们通过一个例子来解释一下。
在下面这段代码中,我们根据配置文件的后缀(json、xml、yaml、properties),选择不同的解析器(JsonRuleConfigParser、XmlRuleConfigParser……),将存储在文件中的配置解析成内存对象 RuleConfig。
public class RuleConfigSource {public RuleConfig load(String ruleConfigFilePath) {String ruleConfigFileExtension = getFileExtension(ruleConfigFilePath);IRuleConfigParser parser = null;if ("json".equalsIgnoreCase(ruleConfigFileExtension)) {parser = new JsonRuleConfigParser();} else if ("xml".equalsIgnoreCase(ruleConfigFileExtension)) {parser = new XmlRuleConfigParser();} else if ("yaml".equalsIgnoreCase(ruleConfigFileExtension)) {parser = new YamlRuleConfigParser();} else if ("properties".equalsIgnoreCase(ruleConfigFileExtension)) {parser = new PropertiesRuleConfigParser();} else {throw new InvalidRuleConfigException("Rule config file format is not supported: " + ruleConfigFilePath);}String configText = "";//从ruleConfigFilePath文件中读取配置文本到configText中RuleConfig ruleConfig = parser.parse(configText);return ruleConfig;}private String getFileExtension(String filePath) {//...解析文件名获取扩展名,比如rule.json,返回jsonreturn "json";}}
为了让代码逻辑更加清晰,可读性更好,我们要善于将功能独立的代码块封装成函数。按照这个设计思路,我们可以将代码中涉及 parser 创建的部分逻辑剥离出来,抽象成 createParser() 函数。重构之后的代码如下所示:
public RuleConfig load(String ruleConfigFilePath) {String ruleConfigFileExtension = getFileExtension(ruleConfigFilePath);IRuleConfigParser parser = createParser(ruleConfigFileExtension);if (parser == null) {throw new InvalidRuleConfigException("Rule config file format is not supported: " + ruleConfigFilePath);}String configText = "";//从ruleConfigFilePath文件中读取配置文本到configText中RuleConfig ruleConfig = parser.parse(configText);return ruleConfig;}//重新封装出来的方法private String getFileExtension(String filePath) {//...解析文件名获取扩展名,比如rule.json,返回jsonreturn "json";}private IRuleConfigParser createParser(String configFormat) {IRuleConfigParser parser = null;if ("json".equalsIgnoreCase(configFormat)) {parser = new JsonRuleConfigParser();} else if ("xml".equalsIgnoreCase(configFormat)) {parser = new XmlRuleConfigParser();} else if ("yaml".equalsIgnoreCase(configFormat)) {parser = new YamlRuleConfigParser();} else if ("properties".equalsIgnoreCase(configFormat)) {parser = new PropertiesRuleConfigParser();}return parser;}}
简单工厂1:为了逻辑清晰,我们可以将创建对象的这块方法封装成函数,并且让类的之职责更加单一(单一职责原则),我们可以将 函数剥离到一个独立的类中,让这个类只负责对象的创建。而这个类就是我们现在要讲的简单工厂模式类。(其实就是一个static方法的类)
具体的代码如下所示:
//...省略上面的load方法public class RuleConfigParserFactory {public static IRuleConfigParser createParser(String configFormat) {IRuleConfigParser parser = null;if ("json".equalsIgnoreCase(configFormat)) {parser = new JsonRuleConfigParser();} else if ("xml".equalsIgnoreCase(configFormat)) {parser = new XmlRuleConfigParser();} else if ("yaml".equalsIgnoreCase(configFormat)) {parser = new YamlRuleConfigParser();} else if ("properties".equalsIgnoreCase(configFormat)) {parser = new PropertiesRuleConfigParser();}return parser;}
简单工厂2:这样每次调用RuleConfigParserFactory的时候都需要创建一个新的解析器对象。如果这个对象可以复用(每次都返回同一个对象),我们可以节省出创建对象的时间和内存,将第一次创建好的对象缓存起来,下次直接从缓存中取,这就类似单例模式+工厂模式的结合。
public class RuleConfigParserFactory {private static final Map<String, RuleConfigParser> cachedParsers = new HashMap<>();static {//这里采用饿汉式的方法,类初始化(第一次调用该类)的时候就会直接先创建好对象放入map中cachedParsers.put("json", new JsonRuleConfigParser());cachedParsers.put("xml", new XmlRuleConfigParser());cachedParsers.put("yaml", new YamlRuleConfigParser());cachedParsers.put("properties", new PropertiesRuleConfigParser());}public static IRuleConfigParser createParser(String configFormat) { //返回实例的方法if (configFormat == null || configFormat.isEmpty()) { //对参数进行简单的判断return null;//返回null还是IllegalArgumentException全凭你自己说了算}//从map(缓存)中取IRuleConfigParser parser = cachedParsers.get(configFormat.toLowerCase());return parser;}}
简单工厂模式缺点:
- 使用使用简单工厂1创建的对象有多处 if 分支判断逻辑,违背开闭原则(每次添加一个parser都要修改原类的逻辑添加一个if),但权衡扩展性和可读性,这样的代码实现在大多数情况下(比如,不需要频繁地添加 parser,也没有太多的 parser)是没有问题的。
- 第二种只符合返回单例同一个对象的情况下(可以省略if,else)
工厂方法【常用】
public interface IRuleConfigParserFactory {IRuleConfigParser createParser();}public class JsonRuleConfigParserFactory implements IRuleConfigParserFactory {@Overridepublic IRuleConfigParser createParser() {return new JsonRuleConfigParser();}}public class XmlRuleConfigParserFactory implements IRuleConfigParserFactory {@Overridepublic IRuleConfigParser createParser() {return new XmlRuleConfigParser();}}public class YamlRuleConfigParserFactory implements IRuleConfigParserFactory {@Overridepublic IRuleConfigParser createParser() {return new YamlRuleConfigParser();}}public class PropertiesRuleConfigParserFactory implements IRuleConfigParserFactory {@Overridepublic IRuleConfigParser createParser() {return new PropertiesRuleConfigParser();}}
这样当我们新增一种 parser 的时候,只需要新增一个实现了 IRuleConfigParserFactory 接口的 Factory 类即可
if ("json".equalsIgnoreCase(ruleConfigFileExtension)) {parserFactory = new JsonRuleConfigParserFactory(); //由原先的直接创建对象,变成创建工厂} else if ("xml".equalsIgnoreCase(ruleConfigFileExtension)) {parserFactory = new XmlRuleConfigParserFactory();} else if ("yaml".equalsIgnoreCase(ruleConfigFileExtension)) {parserFactory = new YamlRuleConfigParserFactory();} else if ("properties".equalsIgnoreCase(ruleConfigFileExtension)) {parserFactory = new PropertiesRuleConfigParserFactory();} else {throw new InvalidRuleConfigException("Rule config file format is not supported: " + ruleConfigFilePath);}IRuleConfigParser parser = parserFactory.createParser();// 利用多态调用工厂方法来创建对象
- 从上面的代码实现来看,工厂类对象的创建逻辑又耦合进了 load() 函数中,跟我们最初的代码版本非常相似,引入工厂方法非但没有解决问题,反倒让设计变得更加复杂了。那怎么来解决这个问题呢?
- 我们可以为工厂类再创建一个简单工厂,也就是工厂的工厂,用来创建工厂类对象。这段话听起来有点绕,我把代码实现出来了,你一看就能明白了。其中,RuleConfigParserFactoryMap 类是创建工厂对象的工厂类,getParserFactory() 返回的是缓存好的单例工厂对象
public class RuleConfigSource {public RuleConfig load(String ruleConfigFilePath) {String ruleConfigFileExtension = getFileExtension(ruleConfigFilePath);//从下面的简单工厂中获取相应的工厂IRuleConfigParserFactory parserFactory = RuleConfigParserFactoryMap.getParserFactory(ruleConfigFileExtension);IRuleConfigParser parser = parserFactory.createParser(); //利用工厂创建对象}//因为工厂类都只包含方法,不包含成员变量,完全可以利用缓存每次返回相同的实例//不需要每次都创建新的工厂类对象,所以,简单工厂模式的第二种实现思路更加合适。public class RuleConfigParserFactoryMap { //工厂的工厂private static final Map<String, IRuleConfigParserFactory> cachedFactories = new HashMap<>();static {cachedFactories.put("json", new JsonRuleConfigParserFactory());cachedFactories.put("xml", new XmlRuleConfigParserFactory());cachedFactories.put("yaml", new YamlRuleConfigParserFactory());cachedFactories.put("properties", new PropertiesRuleConfigParserFactory());}public static IRuleConfigParserFactory getParserFactory(String type) {if (type == null || type.isEmpty()) {return null;}IRuleConfigParserFactory parserFactory = cachedFactories.get(type.toLowerCase());return parserFactory;}}

工厂方法缺点:
- 当我们需要添加新的规则配置解析器的时候,我们只需要创建新的 parser 类和 parser factory 类,并且在 RuleConfigParserFactoryMap 类中,将新的 parser factory 对象添加到 cachedFactories 中即可。代码的改动非常少,基本上符合开闭原则。
- 实际上,对于规则配置文件解析这个应用场景来说,工厂模式需要额外创建诸多 Factory 类,也会增加代码的复杂性,而且,每个 Factory 类只是做简单的 new 操作,功能非常单薄(只有一行代码),也没必要设计成独立的类,所以,在这个应用场景下,简单工厂模式简单好用,比工厂方法模式更加合适。
简单工厂和工厂方法的选择?
- 我们前面提到,之所以将某个代码块剥离出来,独立为函数或者类,原因是这个代码块的逻辑过于复杂,剥离之后能让代码更加清晰,更加可读、可维护。但是,如果代码块本身并不复杂,就几行代码而已,我们完全没必要将它拆分成单独的函数或者工厂类。
- 基于这个设计思想,当对象的创建逻辑比较复杂,不只是简单的 new 一下就可以,而是要组合其他类对象,做各种初始化操作的时候,我们推荐使用工厂方法模式,将复杂的创建逻辑拆分到多个工厂类中,让每个工厂类都不至于过于复杂。而使用简单工厂模式,将所有的创建逻辑都放到一个工厂类中,会导致这个工厂类变得很复杂。
- 除此之外,在某些场景下,如果对象不可复用,那工厂类每次都要返回不同的对象。如果我们使用简单工厂模式来实现,就只能选择第一种包含 if 分支逻辑的实现方式。如果我们还想避免烦人的 if-else 分支逻辑,这个时候,我们就推荐使用工厂方法模式。
抽象工厂【了解】
在简单工厂和工厂方法中,类只有一种分类方式。比如,在规则配置解析那个例子中,解析器类只会根据配置文件格式(Json、Xml、Yaml……)来分类。但是,如果类有两种分类方式,比如,我们既可以按照配置文件格式来分类,也可以按照解析的对象(Rule 规则配置还是 System 系统配置)来分类,那就会对应下面这 8 个 parser 类。
针对规则配置的解析器:基于接口IRuleConfigParserJsonRuleConfigParserXmlRuleConfigParserYamlRuleConfigParserPropertiesRuleConfigParser针对系统配置的解析器:基于接口ISystemConfigParserJsonSystemConfigParserXmlSystemConfigParserYamlSystemConfigParserPropertiesSystemConfigParser
- 针对这种特殊的场景,如果还是继续用工厂方法来实现的话,我们要针对每个 parser 都编写一个工厂类,也就是要编写 8 个工厂类(每个工厂类创建一个对象)。如果我们未来还需要增加针对业务配置的解析器(比如 IBizConfigParser),那就要再对应地增加 4 个工厂类。而我们知道,过多的类也会让系统难维护。这个问题该怎么解决呢?
- 抽象工厂就是针对这种非常特殊的场景而诞生的。我们可以让一个工厂负责创建多个不同类型的对象(IRuleConfigParser、ISystemConfigParser 等),而不是只创建一种 parser 对象。这样就可以有效地减少工厂类的个数。具体的代码实现如下所示:
public interface IConfigParserFactory {IRuleConfigParser createRuleParser();ISystemConfigParser createSystemParser();//此处可以扩展新的parser类型,比如IBizConfigParser}public class JsonConfigParserFactory implements IConfigParserFactory {@Overridepublic IRuleConfigParser createRuleParser() {return new JsonRuleConfigParser();}@Overridepublic ISystemConfigParser createSystemParser() {return new JsonSystemConfigParser();}}public class XmlConfigParserFactory implements IConfigParserFactory {@Overridepublic IRuleConfigParser createRuleParser() {return new XmlRuleConfigParser();}@Overridepublic ISystemConfigParser createSystemParser() {return new XmlSystemConfigParser();}}// 省略YamlConfigParserFactory和PropertiesConfigParserFactory代码
其实就类似工厂方法,原先的工厂方法的接口只是创建RuleConfigParser ,这时候我们再抽象出一层,变成ConfigParser,提供一个RuleConfig和一个JsonConfig的接口,同样的实现类由JsonRuleConfigParser变成JsonConfigParser,实现这两个方法即可。这样能每个工厂都可以创建两个对象

案例:实现一个DI容器
DI容器:我们不需要手动new创建对象,使用依赖注入框架我们只需要通过依赖注入框架提供的扩展点,简单配置一下所有需要创建的类对象、类与类之间的依赖关系(例如Spring中的XML文件),就可以实现由框架来自动创建对象、管理对象的生命周期。
用 Java 语言来实现一个简单的 DI 容器,核心逻辑只需要包括这样两个部分:配置文件解析、根据配置文件通过“反射”语法来创建对象。
最小原型设计
因为我们主要是讲解设计模式,所以,在今天的讲解中,我们只实现一个 DI 容器的最小原型。像 Spring 框架这样的 DI 容器,它支持的配置格式非常灵活和复杂。为了简化代码实现,重点讲解原理,在最小原型中,我们只支持下面配置文件中涉及的配置语法。
配置文件beans.xml<beans><bean id="rateLimiter" class="com.xzg.RateLimiter"><constructor-arg ref="redisCounter"/></bean><bean id="redisCounter" class="com.xzg.redisCounter" scope="singleton" lazy-init="true"><constructor-arg type="String" value="127.0.0.1"><constructor-arg type="int" value=1234></bean></bean
最小原型的使用方式跟 Spring 框架非常类似,示例代码如下所示:
public class Demo {public static void main(String[] args) {ApplicationContext applicationContext = new ClassPathXmlApplicationContext("beans.xml");RateLimiter rateLimiter = (RateLimiter) applicationContext.getBean("rateLimiter");rateLimiter.test();//...}}
提供执行入口
面向对象设计的最后一步是:组装类并提供执行入口。在这里,执行入口就是一组暴露给外部使用的接口和类。通过刚刚的最小原型使用示例代码,我们可以看出,执行入口主要包含两部分:ApplicationContext 和 ClassPathXmlApplicationContext。其中,ApplicationContext 是接口,ClassPathXmlApplicationContext 是接口的实现类。两个类具体实现如下所示:
public interface ApplicationContext {Object getBean(String beanId);}public class ClassPathXmlApplicationContext implements ApplicationContext {private BeansFactory beansFactory;private BeanConfigParser beanConfigParser;public ClassPathXmlApplicationContext(String configLocation) {this.beansFactory = new BeansFactory();this.beanConfigParser = new XmlBeanConfigParser(); //这里可以使用上面讲到的工厂模式来帮我们创建解析器对象(这里没有使用,只创建了一个xml解析器)loadBeanDefinitions(configLocation);//调用下面方法解析}private void loadBeanDefinitions(String configLocation) {InputStream in = null;try {in = this.getClass().getResourceAsStream("/" + configLocation);//将传入的字符串找到对应路径的配置文件if (in == null) {throw new RuntimeException("Can not find config file: " + configLocation);}List<BeanDefinition> beanDefinitions = beanConfigParser.parse(in);//解析器将文件解析,然后封装到pojo类中(见下面)beansFactory.addBeanDefinitions(beanDefinitions);//调用bean工厂添加相应的实例} finally {if (in != null) {try {in.close();} catch (IOException e) {// TODO: log error}}}}@Overridepublic Object getBean(String beanId) {return beansFactory.getBean(beanId); //根据beanId获取实例}}
配置文件解析
配置文件解析主要包含 BeanConfigParser 接口和 XmlBeanConfigParser 实现类,负责将配置文件解析为 BeanDefinition 结构,以便 BeansFactory 根据这个结构来创建对象。配置文件的解析比较繁琐,不涉及我们要讲的理论知识,不是我们讲解的重点,所以这里我只给出两个类的大致设计思路,并未给出具体的实现代码。如果感兴趣的话,你可以自行补充完整。具体的代码框架如下所示:
public interface BeanConfigParser {List<BeanDefinition> parse(InputStream inputStream); //解析流对象List<BeanDefinition> parse(String configContent);//解析字符串类型}public class XmlBeanConfigParser implements BeanConfigParser { //使用工厂方法,实现解析器接口@Overridepublic List<BeanDefinition> parse(InputStream inputStream) {String content = null;// TODO:...如果传入的是流对象,先读出字符串然后使用字符串的方法进行解析return parse(content);}@Overridepublic List<BeanDefinition> parse(String configContent) { //解析方法,将文件中字符串解析成BeanDefinition pojo对象List<BeanDefinition> beanDefinitions = new ArrayList<>();// TODO:...return beanDefinitions;}}public class BeanDefinition {private String id;private String className;private List<ConstructorArg> constructorArgs = new ArrayList<>();private Scope scope = Scope.SINGLETON;private boolean lazyInit = false;// 省略必要的getter/setter/constructorspublic boolean isSingleton() {return scope.equals(Scope.SINGLETON);}public static enum Scope { //使用枚举类来保存对象的单例和多例状态SINGLETON,PROTOTYPE}public static class ConstructorArg {private boolean isRef;private Class type;private Object arg;// 省略必要的getter/setter/constructors}}
核心工厂类设计
- 最后,我们来看,BeansFactory 是如何设计和实现的。这也是我们这个 DI 容器最核心的一个类了。它负责根据从配置文件解析得到的 BeanDefinition 来创建对象。
- 如果对象的 scope 属性是 singleton,那对象创建之后会缓存在 singletonObjects 这样一个 map 中,下次再请求此对象的时候,直接从 map 中取出返回,不需要重新创建。如果对象的 scope 属性是 prototype,那每次请求对象,BeansFactory 都会创建一个新的对象返回。
- 实际上,BeansFactory 创建对象用到的主要技术点就是 Java 中的反射语法:一种动态加载类和创建对象的机制。我们知道,JVM 在启动的时候会根据代码自动地加载类、创建对象。至于都要加载哪些类、创建哪些对象,这些都是在代码中写死的,或者说提前写好的。但是,如果某个对象的创建并不是写死在代码中,而是放到配置文件中,我们需要在程序运行期间,动态地根据配置文件来加载类、创建对象,那这部分工作就没法让 JVM 帮我们自动完成了,我们需要利用 Java 提供的反射语法自己去编写代码。
- 搞清楚了反射的原理,BeansFactory 的代码就不难看懂了。具体代码实现如下所示:
public class BeansFactory {private ConcurrentHashMap<String, Object> singletonObjects = new ConcurrentHashMap<>();private ConcurrentHashMap<String, BeanDefinition> beanDefinitions = new ConcurrentHashMap<>();public void addBeanDefinitions(List<BeanDefinition> beanDefinitionList) {for (BeanDefinition beanDefinition : beanDefinitionList) { //首先根据beanId,将BeanDefinition放入到集合中this.beanDefinitions.putIfAbsent(beanDefinition.getId(), beanDefinition);}for (BeanDefinition beanDefinition : beanDefinitionList) {//根据每个BeanDefinition创建实例if (beanDefinition.isLazyInit() == false && beanDefinition.isSingleton()) {createBean(beanDefinition); //调用下面的创建实例方法}}}public Object getBean(String beanId) {BeanDefinition beanDefinition = beanDefinitions.get(beanId);if (beanDefinition == null) {throw new NoSuchBeanDefinitionException("Bean is not defined: " + beanId);}return createBean(beanDefinition);}@VisibleForTestingprotected Object createBean(BeanDefinition beanDefinition) { //这里就是BeanDefinition pojo类来创建对象的方法if (beanDefinition.isSingleton() && singletonObjects.contains(beanDefinition.getId())) { //判断如果是单例的,并且缓存中有return singletonObjects.get(beanDefinition.getId()); //从缓存中拿}Object bean = null;try { //下面是调用反射来创建对象的过程Class beanClass = Class.forName(beanDefinition.getClassName());List<BeanDefinition.ConstructorArg> args = beanDefinition.getConstructorArgs();if (args.isEmpty()) {bean = beanClass.newInstance();} else {Class[] argClasses = new Class[args.size()];Object[] argObjects = new Object[args.size()];for (int i = 0; i < args.size(); ++i) {BeanDefinition.ConstructorArg arg = args.get(i);if (!arg.getIsRef()) {argClasses[i] = arg.getType();argObjects[i] = arg.getArg();} else {BeanDefinition refBeanDefinition = beanDefinitions.get(arg.getArg());if (refBeanDefinition == null) {throw new NoSuchBeanDefinitionException("Bean is not defined: " + arg.getArg());}argClasses[i] = Class.forName(refBeanDefinition.getClassName());argObjects[i] = createBean(refBeanDefinition);}}bean = beanClass.getConstructor(argClasses).newInstance(argObjects);}} catch (ClassNotFoundException | IllegalAccessException| InstantiationException | NoSuchMethodException | InvocationTargetException e) {throw new BeanCreationFailureException("", e);}if (bean != null && beanDefinition.isSingleton()) { //如果beanDefinition中定义为单例的,则加入到Map缓存中singletonObjects.putIfAbsent(beanDefinition.getId(), bean);return singletonObjects.get(beanDefinition.getId());}return bean;}}
