開發與維運

設計模式最佳套路5 —— 愉快地使用工廠方法模式

2021-08-06

什麼是工廠方法模式

工廠方法模式（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);
    }
}

Leave a Reply

Your email address will not be published. Required fields are marked *