一般情况下，工厂模式分为三种更为细分的类型：简单工厂、工厂方法和抽象工厂。其中，前两者的方法原理比较简单，在实际的项目里也比较常用；而抽象工厂的原理稍微复杂，在实际的项目中相对也不常用。所以，我们今天重点是前两种工厂模式，
简单工厂
在下面这段代码里，我们根据配置文件的后缀（json,xml,yaml, properties），选择不同的解析器(JsonRuleConfigParser, XmlRuleConfigParser)，将存在文件中的配置解析成内存对象RuleConfig
为了让代码逻辑更加清晰、可读性更好，我们要善于把功能独立的代码块封装成函数，按照这个设计思路，我们可以把代码中设计parse创建的部分逻辑剥离出来，抽象成createParse()函数。重构之后的代码如下所示：
为了让类的职责更加单一、代码更加清晰，我们还可以进一步将createParse()函数剥离到一个独立的类中，让这个类只负责对象的创建。而这个类就是简单工厂模式类。
大部分工厂类都是以Factory这个单词结尾的，但是也不是必须的；工厂类中创建对象的方法一般是create开头，比如代码里的createParser，但是也有的命名为getInstance()，createInstance()，newInstance，我们根据具体的场景和习惯来命名就好。
在上面的代码里，每次调用RuleConfigParserFactory的createParse的时候，都需要创建一个新的parser。实际上，如果parser可以复用，为了节省内存和对象创建的时间，我们可以把parser事先创建好缓存起来，类似单例模式和工厂模式的结合。
思考1：对于上面两种简单工厂模式的实现方法，如果我们要添加新的parser，那势必要改动到RuleConfigParserFactory的代码，那是不是违反开闭原则呢？
如果不是需要频繁地添加新的parser，只是偶尔修改RuleConfigParserFactory代码，稍微不符合开闭原则，也是可以接受的。
思考2：第一种实现里，有一组if分支判断逻辑，是否需要用多态或其他设计模式替代？
如果if分支不是很多，代码中有if分支也是可以接受的。
使用多态或设计模式替代if分支判断逻辑，虽然提高了代码的扩展性，但是也增加了类的个数，牺牲了代码的可读性。
工厂方法
思考3：如果必须将if分支逻辑去掉，那应该怎么办？
比较经典的方法就是利用多态 重构后的代码如下：
这就是工厂方法模式的典型代码实现，当新增一种parser的时候，只需要新增一个实现了IRuleConfigParserFactory接口的Factory类即可。所以，工厂方法模式比简单工厂更符合开闭原则。
