创建型-工厂模式_destruleconfigpath-CSDN博客

本文链接：https://blog.csdn.net/liang_love_java/article/details/113887508

本文探讨了简单工厂模式和工厂方法模式在对象创建中的应用，强调了何时选择工厂方法模式而非简单工厂模式。通过案例分析了配置文件解析器的创建，展示了如何通过工厂模式封装变化、复用代码并降低复杂性。同时，介绍了抽象工厂模式的概念，总结了何时使用工厂模式的关键考量因素。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

那什么时候该用工厂方法模式，而非简单工厂模式呢？

抽象工厂

总结

场景假设

我们根据配置文件的后缀（json、xml、yaml、properties），选择不同的解析器（JsonRuleConfigParser、XmlRuleConfigParser、YamlRuleConfigParser、PropertiesRuleConfigParser ），将存储在文件中的配置解析成内存对象 RuleConfig。

说明：实例代码中的 IRuleConfigParser 是解析器接口（interface），JsonRuleConfigParser、XmlRuleConfigParser、YamlRuleConfigParser、PropertiesRuleConfigParser 是解析器接口的实现类

代码示例说明

代码仅供说明使用，不考虑健壮性

简单工厂模式

实现方式1：每次都创建新的对象

public class RuleConfigSource {

// 加载配置

public RuleConfig load(String ruleConfigFilePath) {

// 配置文件路径

String configPath = "/Users/liangpeng/sky.json";

// 读取配置

String configText = readConfig(configPath);

// 配置格式

String configFormat = "json";

// 根据配置格式获取配置解析器

IRuleConfigParser parser = RuleConfigParserFactory.createParser(configFormat);

// 将配置信息解析为 RuleConfig 对象

RuleConfig ruleConfig = parser.parse(configText);

return ruleConfig;

}

// 每次创建新对象

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：如果工厂创建出的对象可以复用，可以将对象缓存起来，每次从缓存中取出对象直接使用

public class RuleConfigParserFactory {

private static final Map<String, RuleConfigParser> cachedParsers = new HashMap<>();

static {

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全凭你自己说了算

}

IRuleConfigParser parser = cachedParsers.get(configFormat.toLowerCase());

return parser;

}

尽管“简单工厂模式”的代码实现方式1中，有多处 if 分支判断逻辑，违背开闭原则，但权衡扩展性和可读性，这样的代码实现在大多数情况下（比如，不需要频繁地添加 parser，也没有太多的 parser）是没有问题的。

工厂方法模式

如果我们非得要将 if 分支逻辑去掉，那该怎么办呢？比较经典处理方法就是利用多态。按照多态的实现思路，对上面的代码进行重构。重构之后的代码如下所示：

// 工厂接口

public interface IRuleConfigParserFactory {

IRuleConfigParser createParser();

}

public class JsonRuleConfigParserFactory implements IRuleConfigParserFactory {

@Override

public IRuleConfigParser createParser() {

return new JsonRuleConfigParser();

}

public class XmlRuleConfigParserFactory implements IRuleConfigParserFactory {

@Override

public IRuleConfigParser createParser() {

return new XmlRuleConfigParser();

}

public class YamlRuleConfigParserFactory implements IRuleConfigParserFactory {

@Override

public IRuleConfigParser createParser() {

return new YamlRuleConfigParser();

}

public class PropertiesRuleConfigParserFactory implements IRuleConfigParserFactory {

@Override

public IRuleConfigParser createParser() {

return new PropertiesRuleConfigParser();

}

这就是工厂方法模式的典型代码实现。这样当我们新增一种 parser 的时候，只需要新增一个实现了 IRuleConfigParserFactory 接口的 Factory 类即可。所以，工厂方法模式比起简单工厂模式更加符合开闭原则。

从上面的工厂方法的实现来看，一切都很完美，但是实际上存在挺大的问题。问题存在于这些工厂类的使用上。接下来，我们看一下，如何用这些工厂类来实现 RuleConfigSource 的 load() 函数。具体的代码如下所示：

public class RuleConfigSource {

public RuleConfig load(String ruleConfigFilePath) {

// 配置文件路径

String configPath = "/Users/liangpeng/sky.json";

// 读取配置

String configText = readConfig(configPath);

// 配置格式

String configFormat = "json";

// 根据配置格式获取解释器工厂类

IRuleConfigParserFactory parserFactory = createParserFactory(configFormat);

// 创建解析器

IRuleConfigParser parser = parserFactory.createParser();

RuleConfig ruleConfig = parser.parse(configText);

return ruleConfig;

}

// 根据配置格式获取解释器工厂类

private IRuleConfigParserFactory createParserFactory(configFormat) {

IRuleConfigParserFactory parserFactory = null;

if ("json".equalsIgnoreCase(configFormat)) {

parserFactory = new JsonRuleConfigParserFactory();

} else if ("xml".equalsIgnoreCase(configFormat)) {

parserFactory = new XmlRuleConfigParserFactory();

} else if ("yaml".equalsIgnoreCase(configFormat)) {

parserFactory = new YamlRuleConfigParserFactory();

} else if ("properties".equalsIgnoreCase(configFormat)) {

parserFactory = new PropertiesRuleConfigParserFactory();

}

从上面的代码实现来看，工厂类对象的创建逻辑又耦合进了 load() 函数中，跟我们最初的代码版本非常相似，引入工厂方法非但没有解决问题，反倒让设计变得更加复杂了。那怎么来解决这个问题呢？

我们可以为工厂类再创建一个简单工厂，也就是工厂的工厂，用来创建工厂类对象或者说用来管理工厂类对象。代码如下，其中 RuleConfigParserFactoryMap 类是创建工厂对象的工厂类，getParserFactory() 返回的是缓存好的单例工厂对象。

public class RuleConfigSource {

public RuleConfig load(String ruleConfigFilePath) {

// 配置文件路径

String configPath = "/Users/liangpeng/sky.json";

// 读取配置

String configText = readConfig(configPath);

// 配置格式

String configFormat = "json";

// 根据配置格式获取配置解析工厂

IRuleConfigParserFactory parserFactory = RuleConfigParserFactoryMap.getParserFactory(configFormat);

// 获取配置解析器

IRuleConfigParser parser = parserFactory.createParser();

// 解析配置

RuleConfig ruleConfig = parser.parse(configText);

return ruleConfig;

}

//因为工厂类只包含方法，不包含成员变量，完全可以复用，

// 不需要每次都创建新的工厂类对象，所以，简单工厂模式的第二种实现思路更加合适。

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;

}

那什么时候该用工厂方法模式，而非简单工厂模式呢？

将复杂代码剥离出来，独立为函数或者类。剥离之后能让代码更加清晰，更加可读、可维护。但是，如果代码块本身并不复杂，就几行代码而已，我们完全没必要将它拆分成单独的函数或者类。

基于这个设计思想，当对象的创建逻辑比较复杂，不只是简单的 new 一下就可以，而是要组合其他类对象，做各种初始化操作的时候，我们推荐使用工厂方法模式，将复杂的创建逻辑拆分到多个工厂类中，让每个工厂类都不至于过于复杂。而使用简单工厂模式，将所有的创建逻辑都放到一个工厂类中，会导致这个工厂类变得很复杂。

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

抽象工厂

定义：抽个毛线抽

总结

当创建逻辑比较复杂，是一个“大工程”的时候，我们就考虑使用工厂模式，封装对象的创建过程，将对象的创建和使用相分离。何为创建逻辑比较复杂呢？我总结了下面两种情况。

第一种情况：类似规则配置解析的例子，代码中存在 if-else 分支判断，动态地根据不同的类型创建不同的对象。针对这种情况，我们就考虑使用工厂模式，将这一大坨 if-else 创建对象的代码抽离出来，放到工厂类中。
还有一种情况，尽管我们不需要根据不同的类型创建不同的对象，但是，单个对象本身的创建过程比较复杂，比如前面提到的要组合其他类对象，做各种初始化操作。在这种情况下，我们也可以考虑使用工厂模式，将对象的创建过程封装到工厂类中

对于第一种情况，当每个对象的创建逻辑都比较简单的时候，我推荐使用简单工厂模式，将多个对象的创建逻辑放到一个工厂类中。

当每个对象的创建逻辑都比较复杂的时候，为了避免设计一个过于庞大的简单工厂类，我推荐使用工厂方法模式，将创建逻辑拆分得更

细，每个对象的创建逻辑独立到各自的工厂类中。同理，对于第二种情况，因为单个对象本身的创建逻辑就比较复杂，所以，我建议使

用工厂方法模式。

除了刚刚提到的这几种情况之外，如果创建对象的逻辑并不复杂，那我们就直接通过 new 来创建对象就可以了，不需要使用工厂模式。

现在，我们上升一个思维层面来看工厂模式，它的作用无外乎下面这四个。这也是判断要不要使用工厂模式的最本质的参考标准。