一般情况下，工厂模式分为三种更加细分的类型：简单工厂、工厂方法和抽象工厂。不过，在 GoF 的《设计模式》一书中，它将简单工厂模式看作是工厂方法模式的一种特例，所以工厂模式只被分成了工厂方法和抽象工厂两类。实际上，前面一种分类方法更加常见。

简单工厂

在下面这段代码中，我们根据配置文件的后缀（json、xml、yaml），选择不同的解析器（JsonRuleConfigParser、XmlRuleConfigParser……），将存储在文件中的配置解析成内存对象 RuleConfig。

public class RuleConfigSource 
{ 
    public RuleConfig Load(string ruleConfigFilePath) 
    {
        string ext = GetFileExtension(ruleConfigFilePath);
        IRuleConfigParser parser = null; 
        if (ext == "json") 
        {
            parser = new JsonRuleConfigParser(); 
        } 
        else if (ext == "xml")
        { 
            parser = new XmlRuleConfigParser(); 
        } 
        else if (ext == "yaml") 
        { 
            parser = new YamlRuleConfigParser(); 
        } 
        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 
        return "json"; 
    }
}

为了让代码逻辑更加清晰，可读性更好，我们要善于将功能独立的代码块封装成方法。按照这个设计思路，我们可以将代码中涉及 parser 创建的部分逻辑剥离出来，抽象成 CreateParser() 方法。重构之后的代码如下所示：

public class RuleConfigSource 
{ 
    public RuleConfig Load(string ruleConfigFilePath) 
    {
        string ext = GetFileExtension(ruleConfigFilePath);
        IRuleConfigParser parser = CreateParser(ext); 
        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 
        return "json"; 
    }

    private IRuleConfigParser CreateParser(string ext)
    {
        IRuleConfigParser parser = null;
        if (ext == "json")
        {
            parser = new JsonRuleConfigParser();
        }
        else if (ext == "xml")
        {
            parser = new XmlRuleConfigParser();
        }
        else if (ext == "yaml")
        {
            parser = new YamlRuleConfigParser();
        }
        return parser;
    }
}

为了让类的职责更加单一、代码更加清晰，我们还可以进一步将 CreateParser() 方法剥离到一个独立的类中，让这个类只负责对象的创建。而这个类就是我们现在要讲的简单工厂模式类。具体的代码如下所示：

public class RuleConfigSource 
{ 
    public RuleConfig Load(string ruleConfigFilePath) 
    {
        string ext = GetFileExtension(ruleConfigFilePath);
        IRuleConfigParser parser = RuleConfigParserFactory.CreateParser(ext); 
        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 
        return "json"; 
    }
}

public class RuleConfigParserFactory { 
    public static IRuleConfigParser CreateParser(string ext) 
    {
        IRuleConfigParser parser = null;
        if (ext == "json")
        {
            parser = new JsonRuleConfigParser();
        }
        else if (ext == "xml")
        {
            parser = new XmlRuleConfigParser();
        }
        else if (ext == "yaml")
        {
            parser = new YamlRuleConfigParser();
        }
        return parser;
    }
}

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

工厂方法

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

public interface IRuleConfigParserFactory { 
    IRuleConfigParser CreateParser(); 
}

public class JsonRuleConfigParserFactory : IRuleConfigParserFactory { 
    public override IRuleConfigParser CreateParser() {
        return new JsonRuleConfigParser();
    }
}

public class XmlRuleConfigParserFactory : IRuleConfigParserFactory
{
    public override IRuleConfigParser CreateParser()
    {
        return new XmlRuleConfigParser();
    }
}

public class YamlRuleConfigParserFactory : IRuleConfigParserFactory
{
    public override IRuleConfigParser CreateParser()
    {
        return new YamlRuleConfigParser();
    }
}

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

接下来我们再来看一下工厂方法模式的描述与结构图：

工厂方法模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟到子类。

实际上，对于规则配置文件解析这个应用场景来说，工厂模式需要额外创建诸多 Factory 类，也会增加代码的复杂性，而且，每个 Factory 类只是做简单的 new 操作，功能非常单薄（只有一行代码），也没必要设计成独立的类，所以，在这个应用场景下，简单工厂模式简单好用，比工厂方法模式更加合适。

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

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

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