设计模式最佳套路5 —— 愉快地使用工厂方法模式

本文主要是介绍设计模式最佳套路5 —— 愉快地使用工厂方法模式，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

本篇是设计模式的第五篇，前四篇可见：

设计模式最佳套路1——愉快地使用策略模式

设计模式最佳套路2——愉快地使用管道模式

设计模式最佳套路3——愉快地使用代理模式

设计模式最佳套路4——愉快地使用模板模式

什么是工厂方法模式

工厂方法模式（Factory Method Pattern）也被称为多态工厂模式，其定义了一个创建某种产品的接口，但由子类决定要实例化的产品是哪一个，从而把产品的实例化推迟到子类。

何时使用工厂方法模式

工厂模式一般配合策略模式一起使用，当系统中有多种产品（策略），且每种产品有多个实例时，此时适合使用工厂模式：每种产品对应的工厂提供该产品不同实例的创建功能，从而避免调用方和产品创建逻辑的耦合，完美符合迪米特法则（最少知道原则）。

愉快地使用工厂方法模式

▐ 背景

在平常开发中，我们经常会在 Spring 中实现诸如这样的功能：收集某一类具有共同特征的 Bean（都实现了某个接口或者都打上了某个注解等），然后放入容器中（一般是 Map），使用的时候根据 Bean 的标识，来获取到对应的 Bean。比如我之前文章中的 通过表单标识获得表单对应提交处理器的 FormDataHandlerFactory：

@Component
public class FormDataHandlerFactory {private static final Map<String, FormDataHandler> FORM_DATA_HANDLER_MAP = new HashMap<>(16);/*** 根据表单标识，获取对应的 Handler** @param formCode 表单标识* @return 表单对应的 Handler*/public FormDataHandler getHandler(String formCode) {return FORM_DATA_HANDLER_MAP.get(formCode);}@Autowiredpublic void setFormDataHandlers(List<FormDataHandler> handlers) {for (FormDataHandler handler : handlers) {FORM_DATA_HANDLER_MAP.put(handler.getFormCode(), handler);}}
}

通过表单项类型获得表单项转换器的 FormItemConverterFactory：

@Component
public class FormItemConverterFactory {private static final EnumMap<FormItemTypeEnum, FormItemConverter> CONVERTER_MAP = new EnumMap<>(FormItemTypeEnum.class);/*** 根据表单项类型获得对应的转换器** @param type 表单项类型* @return 表单项转换器*/public FormItemConverter getConverter(FormItemTypeEnum type) {return CONVERTER_MAP.get(type);}@Autowiredpublic void setConverters(List<FormItemConverter> converters) {for (final FormItemConverter converter : converters) {CONVERTER_MAP.put(converter.getType(), converter);}}
}

在我见过的系统中，看到过非常多类似的代码，每次需要这样的功能，就是定义一个新的 XxxFactory，甚至还有直接在调用者里面直接写上这些获取对应 Bean 的代码，直接违反单一原则。在这个时候，其实我们已经趋近于使用工厂方法模式，我们更倾向于称这种 XxxFactory 为简单工厂。不停地使用这种简单工厂的问题在于会导致重复的代码，因而也就自然而然的违背了 DRY 原则（Don't Repeat Yourself）。虽然重复的代码并不多，但是对于我们 Programmer 来说，写重复的代码无异于往我们脸上吐唾沫 —— 是可忍，孰不可忍！

所以接下来基于上面这个场景，我分享一下我目前基于 Spring 实现工厂方法模式的 “最佳套路”（如果你有更好的套路，欢迎赐教和讨论哦）~

▐ 方案

其实设计模式的核心就在于，找出变化的部分，然后对变化进行抽象和封装，从而使得代码能够满足面向对象的基本原则。对于工厂方法模式来说，变化的是产品、工厂，因而我们可以先定义出抽象的产品和抽象的工厂。

抽象的产品（策略）：

public interface Strategy<T> {/*** 获得策略的标识*/T getId();
}

每个产品必须实现 Strategy 接口，代表每个产品必须有一个唯一的标识。

抽象的策略工厂：

public abstract class StrategyFactory<T, S extends Strategy<T>> implements InitializingBean, ApplicationContextAware {private Map<T, S> strategyMap;private ApplicationContext appContext;/*** 根据策略 id 获得对应的策略的 Bean** @param id 策略 id* @return 策略的 Bean*/public S getStrategy(T id) {return strategyMap.get(id);}/*** 获取策略的类型（交给子类去实现）** @return 策略的类型*/protected abstract Class<S> getStrategyType();@Overridepublic void afterPropertiesSet() {// 获取 Spring 容器中，所有 S 类型的 BeanCollection<S> strategies = appContext.getBeansOfType(getStrategyType()).values();strategyMap = Maps.newHashMapWithExpectedSize(strategies.size());// 将所有 S 类型的 Bean 放入到 strategyMap 中for (final S strategy : strategies) {T id = strategy.getId();strategyMap.put(id, strategy);}}@Overridepublic void setApplicationContext(ApplicationContext applicationContext) throws BeansException {appContext = applicationContext;}
}

Spring 容器在启动的时候，会去扫描工厂指定的类型（Class<S>）的 Bean，并将其注册到工厂中（加入到 strategyMap）。所以对于工厂中产品的生产过程，借助 Spring，我们躺好就行。

接下来基于我们的抽象产品和抽象工厂，我们重构上面的两个 Factory：

通过表单标识获得表单对应提交处理器的 FormDataHandlerFactory

@Component
public class FormDataHandlerFactory extends StrategyFactory<String, FormDataHandler> {@Overrideprotected Class<FormDataHandler> getStrategyType() {return FormDataHandler.class;}
}

FormDataHandlerFactory 只需要指定一下其产品类型为 FormDataHandler。当然，FormDataHandler 我们也需要改造一下：

public interface FormDataHandler extends Strategy<String> {@Overridedefault String getId() { return getFormCode(); }String getFormCode();CommonResponse<Object> submit(FormSubmitRequest request);
}

通过表单项类型获得表单项转换器的 FormItemConverterFactory

@Component
public class FormItemConverterFactory extends StrategyFactory<FormItemTypeEnum, FormItemConverter> {@Overrideprotected Class<FormItemConverter> getStrategyType() {return FormItemConverter.class;}
}

此时，FormItemConverterFactory 也只需要指定一下产品的类型，不再会写重复代码。同理，需要改造一下 FormItemConverter：

public interface FormItemConverter extends Strategy<FormItemTypeEnum> {@Overridedefault FormItemTypeEnum getId() { return getType(); }FormItemTypeEnum getType();FormItem convert(FormItemConfig config);
}

如果这个时候新加一个通过列表标识获得列表数据拉取器的 ListDataFetcherFactory，那么首先定义出获取列表数据的接口（产品）：

public interface ListDataFetcher extends Strategy<String> {CommonResponse<JSONObject> fetchData(ListDataFetchRequest request);
}

然后再实现 ListDataFetcherFactory（工厂）：

@Component
public class ListDataFetcherFactory extends StrategyFactory<String, ListDataFetcher> {@Overrideprotected Class<ListDataFetcher> getStrategyType() {return ListDataFetcher.class;}
}

通过抽象产品 Strategy 和抽象工厂 StrategyFactory，我们的代码完美符合了 DRY 原则。

优化

▐ 借助反射

借助反射，我们还可以使得工厂代码变得更加简单：因为如果父类包含泛型参数，且子类对泛型参数进行了具体化，那么这个具体化的泛型类型，可在运行时获取到。基于这个特性，我们可以改造 StrategyFactory：

public abstract class StrategyFactory<T, S extends Strategy<T>>implements InitializingBean, ApplicationContextAware {.../*** 通过反射获取策略的类型** @return 策略的类型*/protected Class<S> getStrategyType() {// getClass 获取当前运行时实例的类，getGenericSuperclass 获得泛型父类Type superclass = getClass().getGenericSuperclass();ParameterizedType pt = (ParameterizedType) superclass;Type[] actualTypeArguments = pt.getActualTypeArguments();// 获得索引为 1 的实际参数类型，即第二个实际参数的类型Type actualTypeArgument = actualTypeArguments[1];@SuppressWarnings("unchecked")Class<S> result = (Class<S>) actualTypeArgument;return result;}...
}

那么上面三个 Factory 写起来就更简单了：

@Component
public class FormDataHandlerFactory extends StrategyFactory<String, FormDataHandler> {}

@Component
public class FormItemConverterFactory extends StrategyFactory<FormItemTypeEnum, FormItemConverter> {}

@Component
public class ListDataFetcherFactory extends StrategyFactory<String, ListDataFetcher> {}

▐ 组合优先于继承

上述的方案是通过继承，并借助泛型的反射功能，由子类来指定策略（ S getStrategyType）的类型。如果工厂类型较多，那么每次新加一个工厂类，容易导致 “类爆炸”。对于上述的方案，变化的部分就是策略的类型，除了继承，我们还可以通过组合来解决这个变化。修改我们的 StrategyFactory：

public class StrategyFactory<T, S extends Strategy<T>>implements InitializingBean, ApplicationContextAware {private final Class<S> strategyType;private Map<T, S> strategyMap;private ApplicationContext appContext;/*** 创建一个策略工厂* * @param strategyType 策略的类型*/public StrategyFactory(Class<S> strategyType) {this.strategyType = strategyType;}/*** 根据策略 id 获得对应的策略的 Bean** @param id 策略 id* @return 策略的 Bean*/public S getStrategy(T id) {return strategyMap.get(id);}@Overridepublic void afterPropertiesSet() {// 获取 Spring 容器中，所有 S 类型的 BeanCollection<S> strategies = appContext.getBeansOfType(strategyType).values();strategyMap = Maps.newHashMapWithExpectedSize(strategies.size());// 将 所有 S 类型的 Bean 放入到 strategyMap 中for (final S strategy : strategies) {T id = strategy.getId();strategyMap.put(id, strategy);}}@Overridepublic void setApplicationContext(ApplicationContext applicationContext) throws BeansException {appContext = applicationContext;}
}

此时 StrategyFactory 不再是抽象类，并且为 StrategyFactory 引入一个新的属性 strategyType，并且在构造 StrategyFactory 就必须设置当前工厂中的策略（产品）类型。那么对于 FormDataHandlerFactory、FormItemConverterFactory 和 ListDataFetcherFactory，我们不需要再通过继承产生，直接通过配置进行组合即可：

@Configuration
public class FactoryConfig {@Beanpublic StrategyFactory<String, FormDataHandler> formDataHandlerFactory() {return new StrategyFactory<>(FormDataHandler.class);}@Beanpublic StrategyFactory<FormItemTypeEnum, FormItemConverter> formItemConverterFactory() {return new StrategyFactory<>(FormItemConverter.class);}@Beanpublic StrategyFactory<String, ListDataFetcher> listDataFetcherFactory() {return new StrategyFactory<>(ListDataFetcher.class);}
}