设计模式-工厂方法模式详解

---

一、工厂方法模式概述

考虑这样一个系统，使用简单工厂模式设计的按钮工厂类可以返回一个具体类型的按钮实例，例如圆形按钮，矩形按钮、菱形按钮等。在这个系统中如果需要增加一种新类型的按钮，例如椭圆形按钮，那么除了增加一个新的具体产品类之外还需要修改工厂类的代码，这就使得整个设计在一定程度上违反了开闭原则。
现在对该系统进行修改，不再提供一个按钮工厂来统一负责所有产品的创建，而是将具体按钮的创建过程交给专门的工厂子类去完成。先定义一个抽象的按钮工厂类，再定义具体的工厂类来生产圆形按钮、矩形按钮、菱形按钮等，它们实现了在抽象按钮工厂类中声明的方法。这种抽象化的结果是使得这种结构可以在不修改具体工厂类的情况下引进新的产品，如果出现新的按钮类型，只需要为这种新类型的按钮定义一个具体的工厂就可以创建该新按钮的实例，这种改进的设计方案即为工厂方法模式。

二、工厂方法模式结构与实现

定义

工厂方法模式：定义一个用于创建对象的接口，但是让子类决定将哪一个类实例化。工厂方法模式让一个类的实例化延迟到其子类。

工厂方法模式结构

工厂方法模式提供一个抽象工厂接口来声明抽象工厂方法，而由其子类来具体实现工厂方法，创建具体的产品对象。

Produc：它是定义产品的接口，是工厂方法模式所创建对象的超类型，也就是产品对象的公共父类。
ConcreteProduct：它实现了抽象产品接口，某种类型的具体产品由专门的具体工厂创建，具体工厂和具体产品之间一一对应。
Factor：在抽象工厂类中声明了工厂方法，用于返回一个产品。抽象工厂是工厂方法模式的核心，所有创建对象的工厂类都必须实现该接口。
ConcreteFactory：它是抽象工厂类的子类，实现了在抽象工厂中声明的工厂方法，并可由客户端调用，返回一个具体产品类的实例。
个人理解总结：有简单开发项目经历的朋友应该能大概明白，其实我认为简单工厂与工厂模式的区别就相当于，我们使用SpringBoot开发项目中的Service层功能一样，简单工厂仅靠Service类进行功能实现，而一般工厂在这一基础上使Service变为一个接口，分离出ServiceImpl层进行功能实现。

实现

与简单工厂模式相比，工厂方法模式最重要的特点是引入了抽象工厂角色，抽象工厂可以是接口，也可以是抽象类或者具体类。

public interface Factory{
	public Product factoryMethod();
}

在抽象工厂中声明了工厂方法但并未实现工厂方法，具体产品对象的创建由子类负责，可在运行时再指定具体工厂类。

public class ConcreteFactory implements Factory{
	public Product factoryMethod(){
		return new ConcreteProduct();
		}
}

实例

Logger接口充当抽象产品，其子类FileLogger和DatabaseLogger充当具体产品，LoggerFactory接口充当抽象工厂，其子类FileLoggerFactory和DatabaseLoggerFactory充当具体工厂。

工厂方法模式的优缺点

优点

1. 在工厂方法模式种，工厂方法用来创建客户所需要的产品，同时还向客户隐藏了哪种具体产品类将被实例化这一细节，用户只需要关系所需产品对应的工厂，无须关心创建细节，甚至无须知道具体产品类的类名。
2. 基于工厂角色和产品角色的多态性设计使工厂方法模式的关键。它能够让工厂自主确定创建何种产品对象，而如何创建这个对象的细节完全封装在具体工厂内部。工厂方法模式之所以又被称为多态工厂模式，正是因为所有的具体工厂类都具有同一抽象父类。
3. 使用工厂方法模式的另一个优点是在系统中加入新产品时无须修改抽象工厂和抽象产品提供的接口，无须修改客户端，也无须修改其他的具体工厂和具体产品，而只要添加一个具体工厂和具体产品即可，这样系统的可扩展性就会变得非常好，完全符合开闭原则。

缺点

1. 在添加新产品时需要编写新的具体产品类，而且还要提供与之对应的具体工厂类，系统中类的个数将成对增加，在一定程度上增加了系统的复杂度，有更多的类需要编译和运行，会给系统带来一些额外的开销。
2. 由于考虑到系统的可扩展性，需要引入抽象层，在客户端代码中均使用抽象层进行定义，增加了系统的抽象性和理解难度。