简单工厂模式和工厂方法模式

心已赠人 2022-11-15 01:09 193阅读 0赞

**简单工厂模式**

我们来看下面一种场景，在我们日常的开发中，会涉及到很多的配置文件，配置文件的存储、加载和使用往往都很重要。下面我们来看一种场景，我们的配置文件的后缀是（json、xml、yaml、redis和properties等）来表示配置文件的存储形式。我们针对不同的存储形式采用不同的方式加载、解析配置文件，然后装载到内存中的RuleConfig对象。

/**
     * 配置对象
     */
    public class RuleConfig {
    }

我们一般的做法是像下面这样的

public class RuleConfigSource {
        public RuleConfig load(String ruleConfigFilePath) throws InvalidRuleConfigException {
            //获取配置文件的扩展名
            String fileExtension = getFileExtension(ruleConfigFilePath);
    
            IRuleConfigParser parser = null;
            if (fileExtension.equalsIgnoreCase("redis")) {
                parser = new RedisRuleConfigParser();
            } else if (fileExtension.equalsIgnoreCase("json")) {
                parser = new JsonRuleConfigParser();
            } else if (fileExtension.equalsIgnoreCase("xml")) {
                parser = new XmlRuleConfigParser();
            } else if (fileExtension.equalsIgnoreCase("yaml")) {
                parser = new YamlRuleConfigParser();
            } else {
                throw new InvalidRuleConfigException("this fileExtension is not supported :" + ruleConfigFilePath);
            }
            //解析配置文件
            RuleConfig ruleConfig = parser.parser(ruleConfigFilePath);
    
            return ruleConfig;
        }
    
        private String getFileExtension(String ruleConfigFilePath) {
            return "redis";
        }

其实如果配置文件支持的格式变化的可能性很小，也就是后续RuleConfigSource中load方法不怎么会修改，那我觉得这样的实现方式是完全没得问题的，即使方法中有很多硬编码，有很多的if...else...。那我觉得也是ok的。

其实我们还可以对load方法进行优化，把根据扩展类型创建不同的解析器相关的方法独立成一个方法，提高代码的可读性。

public class RuleConfigSource {
        public RuleConfig load(String ruleConfigFilePath) throws InvalidRuleConfigException {
            //获取配置文件的扩展名
            String fileExtension = getFileExtension(ruleConfigFilePath);
    
            //根据扩展类型加载对应的解析器
            IRuleConfigParser parser = createParser(fileExtension);
            if (parser == null) {
                throw new InvalidRuleConfigException("this fileExtension is not supported :" + ruleConfigFilePath);
            }
            //解析配置文件
            RuleConfig ruleConfig = parser.parser(ruleConfigFilePath);
    
            return ruleConfig;
        }
    
        private IRuleConfigParser createParser(String fileExtension) {
            IRuleConfigParser parser = null;
            if (fileExtension.equalsIgnoreCase("redis")) {
                parser = new RedisRuleConfigParser();
            } else if (fileExtension.equalsIgnoreCase("json")) {
                parser = new JsonRuleConfigParser();
            } else if (fileExtension.equalsIgnoreCase("xml")) {
                parser = new XmlRuleConfigParser();
            } else if (fileExtension.equalsIgnoreCase("yaml")) {
                parser = new YamlRuleConfigParser();
            }
            return parser;
        }
    
        /**
         * 获取配置文件的扩展名
         *
         * @param ruleConfigFilePath
         * @return
         */
        private String getFileExtension(String ruleConfigFilePath) {
            return "redis1";
        }
    }

为了让类的职责更加单一，其实我们可以把根据扩展类型创建对应解析器相关的逻辑封装成一个单独的类，这个类的职责就是根据扩展类型创建对应的解析器。可以认为是解析器的创建工厂，一般就是XxxYyyFactory这样的形式。

那此处我们可以把创建解析器相关的逻辑剥离出来，并且定义为RuleConfigParserFactory

public class RuleConfigParserFactory {
        public static IRuleConfigParser createParser(String fileExtension) {
            IRuleConfigParser parser = null;
            if (fileExtension.equalsIgnoreCase("redis")) {
                parser = new RedisRuleConfigParser();
            } else if (fileExtension.equalsIgnoreCase("json")) {
                parser = new JsonRuleConfigParser();
            } else if (fileExtension.equalsIgnoreCase("xml")) {
                parser = new XmlRuleConfigParser();
            } else if (fileExtension.equalsIgnoreCase("yaml")) {
                parser = new YamlRuleConfigParser();
            }
            return parser;
        }
    }

经过这样的划分，我们的类RuleConfigSource 和 RuleConfigParserFactory 的职责就会变得更加单一。而且职责分工也更加明确。这就是简单工厂模式啦。

其实在有些场景下，我们可以把单例模式和简单工厂模式进行结合，如下所示的设计思路。

public class RuleConfigParserFactory {
        private static final Map<String, IRuleConfigParser> map = new HashMap<>();
    
        static {
            map.put("xml", new XmlRuleConfigParser());
            map.put("yaml", new YamlRuleConfigParser());
            map.put("json", new JsonRuleConfigParser());
            map.put("redis", new RedisRuleConfigParser());
        }
    
        public static IRuleConfigParser createParser(String fileExtension) {
            if (fileExtension == null || fileExtension.isEmpty()) {
                return null;
            }
            return map.get(fileExtension.toLowerCase());
        }
    }

**工厂方法模式**

其实上面的简单工厂模式，创建每一个解析器的逻辑都比较简单，都是简单的一句new XmlRuleConfigParser（）就可以，其实在这一种场景下，简单工厂模式就完全够用了。但是我们想象一种场景，如果每一个解析器（parser）的创建逻辑都比较复杂，比如Redis相关的解析器需要连接Redis，Redis的管理，数据的读取，数据的处理等等。这个时候把所有解析器的创建逻辑放在同一个工厂里面就会显得比较复杂。不够单一，这时我们就可以把逻辑进行进一步的拆分，拆分成不同的工厂。如下业务逻辑所示。

先定义一个抽象工厂

/**
     * 定义一个抽象工厂
     */
    public interface IRuleConfigParserFactory {
        IRuleConfigParser createParser();
    }

具体工厂，我们以 RedisRuleConfigParserFactory 为例添加一些简单的注释，表明RedisRuleConfigParser的创建比较复杂。

public class XmlRuleConfigParserFactory implements IRuleConfigParserFactory {
        @Override
        public IRuleConfigParser createParser() {
            return new XmlRuleConfigParser();
        }
    }
    
    public class JsonRuleConfigParserFactory implements IRuleConfigParserFactory {
        @Override
        public IRuleConfigParser createParser() {
            return new JsonRuleConfigParser();
        }
    }
    
    public class YamlRuleConfigParserFactory implements IRuleConfigParserFactory {
        @Override
        public IRuleConfigParser createParser() {
            return new YamlRuleConfigParser();
        }
    }
    
    public class RedisRuleConfigParserFactory implements IRuleConfigParserFactory {
        @Override
        public IRuleConfigParser createParser() {
            IRuleConfigParser ruleConfigParser = new RedisRuleConfigParser();
            //读取redis配置文件
            //连接redis
            //初始化解析器
            //....
            return ruleConfigParser;
        }
    }

此时我们的使用如下所示。

public class RuleConfigSource {
        public RuleConfig load(String ruleConfigFilePath) throws InvalidRuleConfigException {
            //获取配置文件的扩展名
            String fileExtension = getFileExtension(ruleConfigFilePath);
    
            //根据扩展类型加载对应的解析器工厂
            IRuleConfigParserFactory parserFactory = null;
            if (fileExtension.equalsIgnoreCase("xml")) {
                parserFactory = new XmlRuleConfigParserFactory();
            } else if (fileExtension.equalsIgnoreCase("redis")) {
                parserFactory = new RedisRuleConfigParserFactory();
            } else if (fileExtension.equalsIgnoreCase("json")) {
                parserFactory = new JsonRuleConfigParserFactory();
            }
            if (parserFactory == null) {
                throw new InvalidRuleConfigException("this fileExtension is not supported :" + ruleConfigFilePath);
            }
    
            //获得对应的解析器
            IRuleConfigParser parser = parserFactory.createParser();
    
            //解析并获取配置对象
            RuleConfig ruleConfig = parser.parser(ruleConfigFilePath);
    
            return ruleConfig;
        }
    }

发现没，这样貌似又回到我们最开始的时候的形式了，if...else...又重新回到用户的逻辑中了。其实要解决这个问题我们可以再加一层工厂，这个工厂负责创建具体的工厂。如下代码所示

public class RuleConfigParserFactoryMap {
        private static final Map<String, IRuleConfigParserFactory> map = new HashMap<>();
    
        static {
            map.put("json", new JsonRuleConfigParserFactory());
            map.put("redis", new RedisRuleConfigParserFactory());
            map.put("xml", new XmlRuleConfigParserFactory());
        }
    
        public static IRuleConfigParserFactory getRuleConfigParserFactory(String fileExtension) {
            if (fileExtension == null || fileExtension.isEmpty()) {
                return null;
            }
            return map.get(fileExtension.toLowerCase());
        }
    }

这样我们就可以把用户使用过程中的if 相关的逻辑拿掉了。

public class RuleConfigSource {
        public RuleConfig load(String ruleConfigFilePath) throws InvalidRuleConfigException {
            //获取配置文件的扩展名
            String fileExtension = getFileExtension(ruleConfigFilePath);
    
            //根据扩展类型加载对应的解析器工厂
            IRuleConfigParserFactory parserFactory = RuleConfigParserFactoryMap.getRuleConfigParserFactory(fileExtension);
    
            if (parserFactory == null) {
                throw new InvalidRuleConfigException("this fileExtension is not supported :" + ruleConfigFilePath);
            }
    
            //获得对应的解析器
            IRuleConfigParser parser = parserFactory.createParser();
    
            //解析并获取配置对象
            RuleConfig ruleConfig = parser.parser(ruleConfigFilePath);
    
            return ruleConfig;
        }
    }

**那到底什么情况下该使用简单工厂，什么情况下该使用工厂方法模式？**

我们之所以将某个代码块剥离出来，独立为函数或者类，原因是这个代码块的逻辑过于复杂，剥离之后能让代码更加清晰，更加可读、可维护。

但是，如果代码块本身并不复杂，就几行代码而已，我们完全没必要将它拆分成单独的函数或者类。基于这个设计思想，**当对象的创建逻辑比较复杂，不只是简单的 new 一下就可以，而是要组合其他类对象，做各种初始化操作的时候**，我们推荐使用工厂方法模式，将复杂的创建逻辑拆分到多个工厂类中，让每个工厂类都不至于过于复杂。

而使用简单工厂模式，将所有的创建逻辑都放到一个工厂类中，会导致这个工厂类变得很复杂。除此之外，在某些场景下，如果对象不可复用，那工厂类每次都要返回不同的对象。如果我们使用简单工厂模式来实现，就只能选择第一种包含 if 分支逻辑的实现方式。如果我们还想避免烦人的 if-else 分支逻辑，这个时候，我们就推荐使用工厂方法模式。

[https://time.geekbang.org/column/article/197254][https_time.geekbang.org_column_article_197254]

[https_time.geekbang.org_column_article_197254]: https://time.geekbang.org/column/article/197254