一般情况下,工厂模式分为三种更为细分的类型:简单工厂、工厂方法和抽象工厂。其中,前两者的方法原理比较简单,在实际的项目里也比较常用;而抽象工厂的原理稍微复杂,在实际的项目中相对也不常用。所以,我们今天重点是前两种工厂模式,
简单工厂
在下面这段代码里,我们根据配置文件的后缀(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类即可。所以,工厂方法模式比简单工厂更符合开闭原则。