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

简介: 工厂模式配合策略模式一起使用,当系统中有多种产品(策略),且每种产品有多个实例时,适合使用工厂模式。

什么是工厂方法模式

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

image.png


何时使用工厂方法模式

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


愉快地使用工厂方法模式

背景

在平常开发中,我们经常会在 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> {
    /**
     * 获得策略的标识
     */
    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();
    @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<S>)的 Bean,并将其注册到工厂中(加入到 strategyMap)。所以对于工厂中产品的生产过程,借助 Spring,我们躺好就行。

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

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

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

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

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

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

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

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

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

image.png

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

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

然后再实现 ListDataFetcherFactory(工厂):

@Component
public class ListDataFetcherFactory extends StrategyFactory<String, ListDataFetcher> {
    @Override
    protected 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);
    }
    @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);
    }
}


相关文章
|
2月前
|
设计模式 数据库连接 PHP
PHP中的设计模式:提升代码的可维护性与扩展性在软件开发过程中,设计模式是开发者们经常用到的工具之一。它们提供了经过验证的解决方案,可以帮助我们解决常见的软件设计问题。本文将介绍PHP中常用的设计模式,以及如何利用这些模式来提高代码的可维护性和扩展性。我们将从基础的设计模式入手,逐步深入到更复杂的应用场景。通过实际案例分析,读者可以更好地理解如何在PHP开发中应用这些设计模式,从而写出更加高效、灵活和易于维护的代码。
本文探讨了PHP中常用的设计模式及其在实际项目中的应用。内容涵盖设计模式的基本概念、分类和具体使用场景,重点介绍了单例模式、工厂模式和观察者模式等常见模式。通过具体的代码示例,展示了如何在PHP项目中有效利用设计模式来提升代码的可维护性和扩展性。文章还讨论了设计模式的选择原则和注意事项,帮助开发者在不同情境下做出最佳决策。
|
1天前
|
设计模式 开发者 Python
Python编程中的设计模式:工厂方法模式###
本文深入浅出地探讨了Python编程中的一种重要设计模式——工厂方法模式。通过具体案例和代码示例,我们将了解工厂方法模式的定义、应用场景、实现步骤以及其优势与潜在缺点。无论你是Python新手还是有经验的开发者,都能从本文中获得关于如何在实际项目中有效应用工厂方法模式的启发。 ###
|
17天前
|
设计模式 Java Kotlin
Kotlin教程笔记(51) - 改良设计模式 - 构建者模式
本教程详细讲解Kotlin语法,适合希望深入了解Kotlin的开发者。对于快速学习Kotlin语法,推荐查看“简洁”系列教程。本文重点介绍了构建者模式在Kotlin中的应用与改良,包括如何使用具名可选参数简化复杂对象的创建过程,以及如何在初始化代码块中对参数进行约束和校验。
16 3
|
2月前
|
设计模式 数据库连接 PHP
PHP中的设计模式:如何提高代码的可维护性与扩展性在软件开发领域,PHP 是一种广泛使用的服务器端脚本语言。随着项目规模的扩大和复杂性的增加,保持代码的可维护性和可扩展性变得越来越重要。本文将探讨 PHP 中的设计模式,并通过实例展示如何应用这些模式来提高代码质量。
设计模式是经过验证的解决软件设计问题的方法。它们不是具体的代码,而是一种编码和设计经验的总结。在PHP开发中,合理地使用设计模式可以显著提高代码的可维护性、复用性和扩展性。本文将介绍几种常见的设计模式,包括单例模式、工厂模式和观察者模式,并通过具体的例子展示如何在PHP项目中应用这些模式。
|
2月前
|
设计模式 Java Spring
spring源码设计模式分析-代理设计模式(二)
spring源码设计模式分析-代理设计模式(二)
|
2月前
|
设计模式
设计模式-工厂模式 Factory Pattern(简单工厂、工厂方法、抽象工厂)
这篇文章详细解释了工厂模式,包括简单工厂、工厂方法和抽象工厂三种类型。每种模式都通过代码示例展示了其应用场景和实现方法,并比较了它们之间的差异。简单工厂模式通过一个工厂类来创建各种产品;工厂方法模式通过定义一个创建对象的接口,由子类决定实例化哪个类;抽象工厂模式提供一个创建相关或依赖对象家族的接口,而不需要明确指定具体类。
设计模式-工厂模式 Factory Pattern(简单工厂、工厂方法、抽象工厂)
|
19天前
|
设计模式 安全 Java
Kotlin教程笔记(51) - 改良设计模式 - 构建者模式
Kotlin教程笔记(51) - 改良设计模式 - 构建者模式
31 0
|
2月前
|
设计模式 Java
Java设计模式-工厂方法模式(4)
Java设计模式-工厂方法模式(4)
|
2月前
|
设计模式 算法 安全
设计模式——模板模式
模板方法模式、钩子方法、Spring源码AbstractApplicationContext类用到的模板方法
设计模式——模板模式
|
3月前
|
设计模式
设计模式-单一职责模式
设计模式-单一职责模式