工厂方法模式 建立型 设计模式(三)

 

工厂方法模式是简单工厂模式的进一步抽象

工厂方法模式既保持了简单工厂模式的优势，又克服了他的缺点

如不清楚简单工厂模式，能够查看前一篇

他是怎么作到的呢？那就是:

核心的工厂角色，再也不是具体的工厂，也就是再也不负责全部具体产品的建立，进一步转变为抽象角色。

他仅仅提供具体工厂子类必须实现的接口  ，再也不关心应该实例化哪一个具体的产品类

具体建立的工做的细节所有交给子类工厂去作

简言之， 从一个类包打天下（简单工厂模式），转换为兄弟姐妹一块儿上（工厂方法）

意图

定义一个用于建立对象的接口，让子类决定实例化哪个类

工厂方法模式使一个类的实例化，延时到其子类（就是在说，子类负责具体产品类的实例化）

别名：虚构造器

 

结构

 

抽象产品Product

产品抽象角色，工厂建立具体的对象的超类或共同接口

具体产品ConcreteProduct

实现了抽象产品Product，ConcreteProduct1 和ConcreteProduct2为具体的产品

抽象工厂Creator

工厂模式的核心，与应用程序无关，全部的工厂都须要实现抽象工厂角色

具体工厂ConcreteCreator

实现了工厂接口的具体的Java类，用于产生具体的产品

 

工厂模式相对于简单工厂模式，产品侧的结构形式不变

而对于工厂，变化很清晰明显

再也不是单一的Java类承担全部的对象建立职责

而是存在工厂的体系结构

Creator做为建立工厂的抽象角色，提供了建立协议，也就是一个方法，约定了咱们将要建立什么范畴的产品

ConcreteCreator1和ConcreteCreator2 是具体的工厂，他们都实现Creator，针对不一样的产品有不一样的工厂 

也就是 产品等级结构是什么样的，就有一个相似结构的工厂等级结构

对应着的工厂建立对应着的产品

就像上图中那样，两个圈中的层级结构是对称的，一 一对应的

Creator对应Product

ConcreteCreator1对应ConcreteProduct1

ConcreteCreator2对应ConcreteProduct2

......

 

 

示例代码

仍是以水果的为例

Fruit Apple Orange与简单工厂模式中同样

此时，再也不是一个水果店卖全部的水果，而是不一样的水果店销售不一样的水果

因此对应水果这种产品的等级结构，也有对应的工厂等级结构

Factory以及 AppleFactory和 OrangeFactory

Fruit Apple 和Orange与简单工厂中的代码相同，请参见上一篇文章，再也不赘述

package factory;
/**
* Created by noteless on 2018/10/9.
* Description:
*/
public interface Factory {
Fruit create();
}

 

package factory;
/**
* Created by noteless on 2018/10/9.
* Description:
*/
public class AppleFactory implements Factory {
@Override
public Fruit create() {
return new Apple();
}
}

 

package factory;
/**
* Created by noteless on 2018/10/9.
* Description:
*/
public class OrangeFactory implements Factory {
@Override
public Fruit create() {
return new Orange();
}
}

 

测试代码

 

工厂方法模式的特色就是平行的等级结构 ，也就是工厂与产品有相对应的层级结构

而不是像简单工厂模式中那样，一个全能类包揽全部建立逻辑

 

对比

工厂方法模式，再也不将逻辑都集中在一个具体的工厂类上

而是借助于抽象的工厂角色Creator，他是一个抽象角色，全部的工厂建立行为分布于他的实现类上

是简单工厂模式的进一步抽象

 

对于工厂模式来讲，若是省略抽象角色Creator，也就好像成了一个或者多个的简单工厂模式

每一个工厂相似一个简单工厂模式

因此 某种程度上说，简单工厂模式是工厂方法模式的一个简化形式或者说特例形式

 

工厂方法模式构造了一个建立对象的工厂框架

与产品等级结构对应的工厂等级结构不就是相等于一个建立框架嘛

由不一样的子类工厂来具体化对象的建立

工厂方法模式还有一个名字叫作 多态性工厂模式

由于具体的工厂都有共同的接口或者共同的抽象父类，具体产品对象由具体的工厂子类建立

建立一个Creator引用指向实际的Creator子类实例，实际建立的对象根据工厂的多态性产生

 

若是系统须要加入一个新的产品时，只须要加入一个新的产品类以及对应的工厂类便可

而 不须要修改已有的抽象工厂角色，也不必修改其余的具体的工厂角色

更不必修改客户端的代码，因此知足了开闭原则

并且 ， 每一个工厂生产一种对应的产品，也符合单一职责原则 

 

在实践中随着业务模式的深刻变得复杂， 若是有多个简单工厂模式，若是他们在某些方面有共性

也是能够考虑将多个简单工厂模式的应用提高为工厂模式的

总结

工厂模式构造了一个与产品等级结构相同的工厂结构，每一个子类工厂建立对应的具体产品

工厂模式是简单模式的进一步抽象

因此想要理解工厂模式只须要理解清楚简单工厂模式便可

工厂模式就是把简单工厂模式中的一类多能，上帝模式，转换为多个工厂类实例分摊职责

能够认为简单工厂模式至关于封建专制，皇帝一我的说了算

工厂模式就至关于民主制度下了，你们群策群力一块儿讨论，每一个人负责一块

 

抽象工厂角色Creator，可使用接口也可使用抽象类（不要用具体的类，由于这自己就是一个抽象角色）

若是具体的工厂之间有相同的逻辑

那么这些逻辑应该被提取到抽象类中

不然，就应该使用接口的形式做为抽象工厂角色Creator和抽象产品角色Product

 

须要注意的是，有不少类提供了不少的方法都可以返回一个具体的对象

好比toString方法，返回一个String

那些算是工厂模式么？

严格的说那些并不属于工厂方法模式

方法是业务逻辑处理，重点在于业务逻辑，而不在于对象的建立

出发点逻辑思想不是一回事，固然，这只是我的见解，是否是都没什么很大争执的必要