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

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

什么是模板模式?
工厂方法模式(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);
}

@Autowired
public 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);
}

@Autowired
public 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 getId();

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

抽象的策略工厂:

public abstract class StrategyFactory>
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();

@Override
public void afterPropertiesSet() {
    // 获取 Spring 容器中,所有 S 类型的 Bean
    Collection<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);
    }
}

@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
    appContext = applicationContext;
}

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

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

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

@Component
public class FormDataHandlerFactory extends StrategyFactory {

@Override
protected Class<FormDataHandler> getStrategyType() {
    return FormDataHandler.class;
}

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

public interface FormDataHandler extends Strategy {

@Override
default String getId() { return getFormCode(); }

String getFormCode();

CommonResponse<Object> submit(FormSubmitRequest request);

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

@Component
public class FormItemConverterFactory extends StrategyFactory {

@Override
protected Class<FormItemConverter> getStrategyType() {
    return FormItemConverter.class;
}

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

public interface FormItemConverter extends Strategy {

@Override
default FormItemTypeEnum getId() { return getType(); }

FormItemTypeEnum getType();

FormItem convert(FormItemConfig config);

}

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

public interface ListDataFetcher extends Strategy {

CommonResponse<JSONObject> fetchData(ListDataFetchRequest request);

}
然后再实现 ListDataFetcherFactory(工厂):

@Component
public class ListDataFetcherFactory extends StrategyFactory {

@Override
protected Class<ListDataFetcher> getStrategyType() {
    return ListDataFetcher.class;
}

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

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

public abstract class StrategyFactory>
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 {}

@Component
public class FormItemConverterFactory extends StrategyFactory {}

@Component
public class ListDataFetcherFactory extends StrategyFactory {}
▐ 组合优先于继承
上述的方案是通过继承,并借助泛型的反射功能,由子类来指定策略( S getStrategyType)的类型。如果工厂类型较多,那么每次新加一个工厂类,容易导致 “类爆炸”。对于上述的方案,变化的部分就是策略的类型,除了继承,我们还可以通过组合来解决这个变化。修改我们的 StrategyFactory:

public class StrategyFactory>
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);
}

@Override
public void afterPropertiesSet() {
    // 获取 Spring 容器中,所有 S 类型的 Bean
    Collection<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);
    }
}

@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
    appContext = applicationContext;
}

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

@Configuration
public class FactoryConfig {

@Bean
public StrategyFactory<String, FormDataHandler> formDataHandlerFactory() {
    return new StrategyFactory<>(FormDataHandler.class);
}

@Bean
public StrategyFactory<FormItemTypeEnum, FormItemConverter> formItemConverterFactory() {
    return new StrategyFactory<>(FormItemConverter.class);
}

@Bean
public StrategyFactory<String, ListDataFetcher> listDataFetcherFactory() {
    return new StrategyFactory<>(ListDataFetcher.class);
}

}

全域营销团队

5分钟解决问题
战斗在阿里电商的核心地带,负责连接供需两端,支持电商营销领域的各类产品、平台和解决方案,其中包括聚划算、百亿补贴、天猫U先、天猫小黑盒、天猫新品孵化、品牌号等重量级业务。我们深度参与双11、618、99划算节等年度大促,不断挑战技术的极限!我们致力于打造幸福感极强的技术团队,有深耕电商精研技术的老司机,也有朝气蓬勃的小萌新,更有可颜可甜的小姐姐,期待具有好奇心和思考力的你的加入!(本篇内容作者:阿里巴巴淘系技术部 之叶)

————————————————————————————————————————

阿里巴巴集团淘系技术部官方账号。淘系技术部是阿里巴巴新零售技术的王牌军,支撑淘宝、天猫核心电商以及淘宝直播、闲鱼、躺平、阿里汽车、阿里房产等创新业务,服务9亿用户,赋能各行业1000万商家。我们打造了全球领先的线上新零售技术平台,并作为核心技术团队保障了11次双十一购物狂欢节的成功。详情可查看我们官网:阿里巴巴淘系技术部官方网站

点击下方主页关注我们,你将收获更多来自阿里一线工程师的技术实战技巧&成长经历心得。另,不定期更新最新岗位招聘信息和简历内推通道,欢迎各位以最短路径加入我们。

相关文章
|
2天前
|
设计模式 算法 Java
跟着GPT学设计模式之模板模式
模板模式是一种行为型设计模式,它定义了一个操作中的算法骨架,将一些步骤的具体实现延迟到子类中。该模式使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。
19 6
|
12天前
|
设计模式 Go
Go语言设计模式:使用Option模式简化类的初始化
在Go语言中,面对构造函数参数过多导致的复杂性问题,可以采用Option模式。Option模式通过函数选项提供灵活的配置,增强了构造函数的可读性和可扩展性。以`Foo`为例,通过定义如`WithName`、`WithAge`、`WithDB`等设置器函数,调用者可以选择性地传递所需参数,避免了记忆参数顺序和类型。这种模式提升了代码的维护性和灵活性,特别是在处理多配置场景时。
45 8
|
20天前
|
设计模式 JavaScript 前端开发
js设计模式【详解】—— 构造函数模式
js设计模式【详解】—— 构造函数模式
21 6
|
25天前
|
设计模式 Java
Java设计模式:工厂模式之简单工厂、工厂方法、抽象工厂(三)
Java设计模式:工厂模式之简单工厂、工厂方法、抽象工厂(三)
|
25天前
|
设计模式 存储 算法
设计模式学习心得之五种创建者模式(2)
设计模式学习心得之五种创建者模式(2)
18 2
|
26天前
|
设计模式 搜索推荐
工厂方法模式-大话设计模式
工厂方法模式-大话设计模式
12 1
|
1月前
|
设计模式 算法
行为型设计模式之模板模式
行为型设计模式之模板模式
|
25天前
|
设计模式 安全 Java
设计模式学习心得之五种创建者模式(1)
设计模式学习心得之五种创建者模式(1)
10 0
|
26天前
|
设计模式
简单工厂模式-大话设计模式
简单工厂模式-大话设计模式
11 0
|
2月前
|
设计模式 Java API
【设计模式】JAVA Design Patterns——Combinator(功能模式)
【设计模式】JAVA Design Patterns——Combinator(功能模式)