Java进阶专题(四) 设计模式之工厂模式
前言
今天开始我们专题的第三课了，开始对设计模式进行讲解，本章节介绍：了解设计模式的由来，介绍设计模式能帮我们解决那些问题以及剖析工厂模式的历史由来及应用场景。本章节参考资料书籍《Spring 5核心原理》中的第一篇 Spring 内功心法（Spring中常用的设计模式）（没有电子档，都是我取其精华并结合自己的理解，一个字一个字手敲出来的）。
回顾软件设计原则
在讲设计模式之前，我们一定要先了解软件设计原则。现在先来回顾一下软件设计七大原则：
开闭原则：对扩展开放，对修改关闭。
依赖倒置原则：通过抽象使各个类或者模块不相互影响，实现松耦合。
单一职责原则：一个类、接口、方法只做一件事。
接口隔离原则：尽量保证接口的纯洁性，客户端不应该依赖不需要的接口。
迪米特法则：又叫最少知道原则，一个类对其所依赖的类知道得越少越好。
里氏替换原则：子类可以扩展父类的功能但不能改变父类原有的功能。
合成复用原则：尽量使用对象组合、聚合，而不使用继承关系达到代码复用的目的。
为什么要从设计模式开始
平时我们写的代码虽然满足了需求但往往不利于项目的开发与维护，通过合理运用设计模式，可以让我们以后维护更方便，因此学会对代码的重构是非常重要的。Spring中对设计模式运用可谓是淋漓尽致，比如：
工厂模式：BeanFactory
装饰器模式：BeanWrapper
代理模式：AopProxy
委派模式：DispatcherServlet
策略模式：HandlerMapping
适配器模式：HandlerAdapter
模板模式：JdbcTemplate
观察者模式：ContextLoaderListener
需要特别声明的是，设计模式从来都不是单个设计模式独立使用的。在实际应用中，通常是多个设计模式混合使用， 你中有我， 我中有你。
工厂模式详解
简单工厂模式
简单工厂模式（Simple Factory Pattern）是指由一个工厂对象决定创建出哪一种产品类的实例，但它不属于GOF，23种设计模式。简单工厂适用于工厂类负责创建的对象较少的场景，且客户端只需要传入对应的参数，工厂就生产对应的对象，对于如何创建对象的逻辑调用方不需要关心。
我们以种植水果为例，先创建种植水果接口IFruit:
public interface IFruit {
/**
* 种植水果方法
*/
void plant();
}
//实现种植苹果
public class Apple implements IFruit {
public void plant() {
System.out.println("种植苹果");
}
}
//实现种植橙子
public class Orange implements IFruit {
public void plant() {
System.out.println("种植橙子");
}
}
我们再看下调用方代码，当想种植某一种水果时候：
public static void main(String[] args) {
//种植苹果
IFruit fruit = new Apple();
fruit.plant();
}
如果此时又要换成种植橙子:
public static void main(String[] args) {
//IFruit fruit = new Apple();
//种植橙子
IFruit fruit = new Orange();
fruit.plant();
}
父类IFruit指向子类Apple的引用，调用方代码需要依赖Aplle，这样随着种植水果的业务越来越多了,调用方的代码就会变得越来越臃肿了。我们要想办法把这种依赖减弱，把创建细节隐藏起来。虽然目前代码中，我们创建的的对象并不复杂，但是从打码设计角度来讲不易扩展。我们用简单工厂对代码进行优化。
创建PlantFruitsFactory工厂：
public static class PlantFruitsFactory {
public IFruit PlantFruit(String fruitName) {
//这里使用的if判断,用switch一样的道理
if ("Apple".equals(fruitName)){
return new Apple();
}else if ("Orange".equals(fruitName)){
return new Orange();
}else {
return null;
}
}
}
修改调用方代码：
public class DemoTest {
public static void main(String[] args) {
IFruit fruit = PlantFruitsFactory.PlantFruit("Apple");
fruit.plant();
}
}
下面我们看下类图:
调用方不再直接关心创建细节，只需要传入指定参数给工厂，工厂负责创建对应的对象给调用方。虽然基本实现了工厂模式的逻辑，但是如果随着业务的扩展，需要创建种植更多品种的水果时，工厂方法每次都需要跟着修改，不符合开闭原则。所以我们还可以再优化下工厂类：
public class PlantFruitsFactory {
//包路径的前缀
private static final String PACKAGE_PATH = "com.study.demo.";
public static IFruit PlantFruit(String fruitName){
try {
return (IFruit) Class.forName(PACKAGE_PATH+fruitName).newInstance();
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
}
这样即使有新需求添加新的水果品种，我们也不需要修改工厂类的代码了，只需要新建一个对应的类，工厂会根据反射创建对应的对象给调用方了。（这里其实还可以优化，可以将方法的入参改为对应的Class对象，这样就不需要强转了，这里就不做演示了。）
简单工厂模式在JDK源码也是无处不在，现在我们来举个例子，例如Calendar类，看
Calendar.getInstance()方法，下面打开的是Calendar的具体创建类：
//源码中的方法
private static Calendar createCalendar(TimeZone zone,
Locale aLocale) {
CalendarProvider provider =
LocaleProviderAdapter.getAdapter(CalendarProvider.class, aLocale)
.getCalendarProvider();
if (provider != null) {
try {
return provider.getInstance(zone, aLocale);
} catch (IllegalArgumentException iae) {
// fall back to the default instantiation
}
}
Calendar cal = null;
if (aLocale.hasExtensions()) {
String caltype = aLocale.getUnicodeLocaleType("ca");
if (caltype != null) {
switch (caltype) {
case "buddhist":
cal = new BuddhistCalendar(zone, aLocale);
break;
case "japanese":
cal = new JapaneseImperialCalendar(zone, aLocale);
break;
case "gregory":
cal = new GregorianCalendar(zone, aLocale);
break;
}
}
}
if (cal == null) {
// If no known calendar type is explicitly specified,
// perform the traditional way to create a Calendar:
// create a BuddhistCalendar for th_TH locale,
// a JapaneseImperialCalendar for ja_JP_JP locale, or
// a GregorianCalendar for any other locales.
// NOTE: The language, country and variant strings are interned.
if (aLocale.getLanguage() == "th" && aLocale.getCountry() == "TH") {
cal = new BuddhistCalendar(zone, aLocale);
} else if (aLocale.getVariant() == "JP" && aLocale.getLanguage() == "ja"
&& aLocale.getCountry() == "JP") {
cal = new JapaneseImperialCalendar(zone, aLocale);
} else {
cal = new GregorianCalendar(zone, aLocale);
}
}
return cal;
}
当然工厂模式也有他的缺点：工厂类的职责相对过重，不易于扩展过于复杂的产品结构。
工厂方法模式
工厂方法模式（FatoryMethod Pattern）是指定义一个创建对象的接口，但让实现这个接口的类来决定实例化哪个类，工厂方法让类的实例化推迟到子类中进行。在工厂方法模式中用户只需要关心所需产品对应的工厂，无须关心创建细节，而且加入新的产品符合开闭原则。
工厂方法模式主要解决产品扩展的问题，在简单工厂中，随着产品链的丰富，如果每个课程的创建逻辑有区别的话，工厂的职责会变得越来越多，有点像万能工厂，并不便于维护。根据单一职责原则我们将职能继续拆分，专人干专事。Apple由Apple工厂创建，Orange由 Orange工厂创建，对工厂本身也做一个抽象。来看代码，先创建IFruitFactory接口：
//工厂接口
public interface IFruitFactory {
IFruit create();
}
//生成苹果的工厂
public class AppleFactory implements IFruitFactory {
@Override
public IFruit create() {
return new Apple();
}
}
//生成橙子的工厂
public class OrangeFactory implements IFruitFactory {
@Override
public IFruit create() {
return new Orange();
}
}
//调用方代码
public class DemoTest {
public static void main(String[] args) {
//创建苹果工厂 生产苹果
IFruitFactory fruitFactory = new AppleFactory();
fruitFactory.create().plant();
//创建橙子工厂 生成橙子
IFruitFactory orangeFactory = new OrangeFactory();
orangeFactory.create().plant();
}
}
现在我们看下类图：
工厂方法适用于以下场景：
1、创建对象需要大量重复的代码。
2、客户端（应用层）不依赖于产品类实例如何被创建、实现等细节。
3、一个类通过其子类来指定创建哪个对象。
工厂方法也有缺点：
1、类的个数容易过多，增加复杂度。
2、增加了系统的抽象性和理解难度。
抽象工厂模式
抽象工厂模式（Abastract Factory Pattern）是指提供一个创建一系列相关或相互依赖产品族产品等级结构一个产品等级结构对象的接口，无须指定他们具体的类。客户端（应用层）不依赖于产品类实例如何被创建、实现等细节，强调的是一系列相关的产品对象（属于同一产品族）一起使用创建对象需要大量重复的代码。需要提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于具体实现。
还是以水果为例，现在水果工厂不仅种植水果还开始加工水果。相当于现在的业务变更为同一个水果类不单纯只是种植水果的功能。在增加两个接口IPlant种植水果和IProcess加工水果。
public interface IPlant {
//种植产品
void plant();
}
public interface IProcess {
//加工产品
void process();
}
然后创建一个抽象工厂FruitFactory:
/**
* 抽象工厂是用户的主入口
* 在 Spring 中应用得最为广泛的一种设计模式
* 易于扩展
*/
public interface FruitFactory {
IPlant createPlant();
IProcess createProcess();
}
然后创建苹果产品线:
//种植苹果
public class ApplePlant implements IPlant {
@Override
public void plant() {
System.out.println("种植苹果");
}
}
//加工苹果
public class AppleProcess implements IProcess {
@Override
public void process() {
System.out.println("加工苹果");
}
}
创建苹果工厂:
public class AppleFactory implements FruitFactory {
@Override
public IPlant createPlant() {
return new ApplePlant();
}
@Override
public IProcess createProcess() {
return new AppleProcess();
}
}
对应的橙子也是一样的。
上面的代码完整地描述了两个产品族苹果和橙子，也描述了两个产品等级种植和加工。抽象工厂非常完美清晰地描述这样一层复杂的关系。但是，不知道大家有没有发现，如果我们再继续扩展产品等级，将出售Sale也加入产品中，那么我们的代码从抽象工厂，到具体工厂要全部调整，很显然不符合开闭原则。因此抽象工厂也是有缺点的：
1、规定了所有可能被创建的产品集合，产品族中扩展新的产品困难，需要修改抽象工厂的接口。
2、增加了系统的抽象性和理解难度。
总结
工厂模式的三种方式，没有绝对的好坏，合适的场景使用合适的模式，实际应用中，我们千万不能犯强迫症甚至有洁癖。在实际需求中产品等级结构升级是非常正常的一件事情。我们可以根据实际情况，只要不是频繁升级，可以不遵循开闭原则。代码每半年升级一次或者每年升级一次又有何不可呢？
