设计模式之静态工厂、工厂方法和抽象工厂的联系与区别

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/sinat_35512245/article/details/54890711

这里写图片描述

解析：

开闭原则：对扩展开放，对修改封闭。静态工厂增加需要是修改源代码，对修改不封闭，不符合开闭原则。

Simple Factory 简单工厂模式（静态工厂）

1）Simple Factory模式属于创建型模式

2）简单工厂模式是由一个工厂（注意是一个！）对象决定创建出哪一种产品类的实例（例如你到肯德基说你要鸡腿，要薯条，要饮料还是其他的，这时肯德基是一个工厂，客户端只需要点明自己要什么就行）

3）实现方式的实质：由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类（这些产品类继承自一个父类或接口）的实例。

UML类图如下：

这里写图片描述

分析：

工厂角色：被客户端直接调用，根据客户端指定传入的参数，动态创建客户端需要的对象；

抽象产品角色：所有对象的父类（接口）；

具体产品角色：即工厂的创建目标，工厂创建的对象就是这些具体类的对象。

可以看出，客户端只面对工厂，不用管产品的具体细节，客户只需向工厂要求你需要什么，其他的事情都交给工厂了。

优点： 通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的．明确了各自的职责和权利。（简单地说，你到肯德基去只需要说你要鸡腿还是鸡翅就行了，不需要去管鸡腿和鸡翅是怎么做出来的，工厂为你提供了这样一个界面）。

不足： 由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。

当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求．这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利；

使用场景

工厂类负责创建的对象比较少； 　　

客户只知道传入工厂类的参数，对于如何创建对象（逻辑）不关心； 　

由于简单工厂很容易违反高内聚责任分配原则，因此一般只在很简单的情况下应用。

从上面的例子也可以看出来，工厂类往往是用反射机制来产生具体对象的。（因为不同类都继承自同一接口），故其扩展性很有限，产品种类必须是事先就知道的哪几种，什么时候你想要添加一个不是公共接口下的具体类就不行了。

另外，如果你不用反射机制，也不要公共接口，在工厂中使用其他逻辑（例如判断传入的字符串）来根据用户参数创建对象也行，那样扩展性也是很糟糕的，逻辑和添加只会越来多。

工厂方法模式

UML类图如下：

这里写图片描述

这个和简单工厂有区别，简单工厂模式只有一个工厂，工厂方法模式对每一个产品都有相应的工厂。

好处：增加一个运算类（例如N次方类），只需要增加运算类和相对应的工厂，两个类，不需要修改工厂类。

缺点：增加运算类，会修改客户端代码，工厂方法只是把简单工厂的内部逻辑判断移到了客户端进行。

Abstract Factory 抽象工厂

UML类图如下：

这里写图片描述

参与者

AbstractFactory——声明一个创建抽象产品对象的操作接口 ConcreteFactory——实现创建具体产品对象的操作 AbstractProduct——为一类产品对象声明一个接口 ConcreteProduct ① 定义一个将被相应的具体工厂创建的产品对象 ② 实现AbstractProduct接口

Client ① 仅使用由AbstractFactory和AbstractProduct类声明的接口

协作

① 通常在运行时刻创建一个ConcreteFactory类的实例。这一具体的工厂创建具有特定实现的产品对象。为创建不同的产品对象，客户应适用不同的具体工厂。

②AbstractFactory将产品对象的创建延迟到它的ConcreteFactory子类。

工厂方法模式：① 一个抽象产品类，可以派生出多个具体产品类。 　　　　　　　② 一个抽象工厂类，可以派生出多个具体工厂类。 　　　　　　　③ 每个具体工厂类只能创建一个具体产品类的实例。

抽象工厂模式：① 多个抽象产品类，每个抽象产品类可以派生出多个具体产品类。 　　　　　　　② 一个抽象工厂类，可以派生出多个具体工厂类。 　　　　　　　③ 每个具体工厂类可以创建多个具体产品类的实例。

区别：① 工厂方法模式只有一个抽象产品类，而抽象工厂模式有多个。 ② 工厂方法模式的具体工厂类只能创建一个具体产品类的实例，而抽象工厂模式可以创建多个。