设计模式之扩展- 论抽象工厂与工厂方法模式的不同

前情提要

由于这几天一直在写关于工厂模式的文章，发现了一个问题，不大不小。在工厂方法模式与抽象工厂模式之间，似乎它俩之间的差别不是太大。所以特意开一篇文章讲讲它俩的区别。

产品维度

工厂方法模式：只围绕着一类接口来进行对象的创建与使用，使用场景单一和简单
抽象工厂模式：提供了一个用于创建相关或相关对象族的接口。

UML类图

从UML类图 我们可以看到两种模式对应的抽象类型也是不一样的。工厂方法模式围绕着射击来进行对象的创建，而抽象模式则围绕 子弹 弹夹 瞄准镜 创建对应的工厂生成相关的对象族。

实现上的分别

比如我们对某些配置的解析；
针对规则配置的解析器：RuleConfigParser
JsonRuleConfigParser
XmlRuleConfigParser
YamlRuleConfigParser

针对系统配置的解析器：基于接口 SystemConfigParser
JsonSystemConfigParser
XmlSystemConfigParser
YamlSystemConfigParser

针对上面这种情景，如果继续使用工厂方法来实现的话，我们就可能需要编写8个工厂类，
因为一个parser就要编写一个工厂类了。而且对于维护的话 也是不太好的。
这时我们就可以采用抽象工厂模式了，可以让一个工厂负责创建多个不同类型的对象，而不是
只创建一种parser对象。我们来看看具体代码如何实现：

interface ConfigParserFactory
{
    public function createRuleParser();
    public function createSystemParser();
}

class JsonConfigParserFactory implements ConfigParserFactory
{
    public function createRuleParser()
    {
        return new JsonRuleConfigParser();
    }

    public function createSystemParser()
    {
        return new JsonSystemParser();
    }
}

class XmlConfigParserFactory implements ConfigParserFactory
{
    public function createRuleParser()
    {
        return new XmlRuleConfigParser();
    }

    public function createSystemParser()
    {
        return new XmlSystemParser();
    }
}

总结

工厂方法模式只有一个维度 产品和工厂是完全对应的。具体到实现类。
抽象工厂模式两个维度，工厂与产品两个维度，其中一个是从产品派生出来的。系统配置，规则配置这些产品类别的划分。另一个维度是从工厂派生出来的，有不同配置的工厂。
工厂模式对于只需要 json规则配置的工厂就已经足够了，但是存在一部分工厂不单单只需要json规则配置，他还要json系统配置等，所以更进一步抽象出抽象工厂。

希望各位能提出自己宝贵的建议，与诸君共同成长。！！十分感谢！