本篇是设计模式的第五篇,前四篇可见:
什么是工厂方法模式
工厂方法模式(Factory Method Pattern)也被称为多态工厂模式,其定义了一个创建某种产品的接口,但由子类决定要实例化的产品是哪一个,从而把产品的实例化推迟到子类。
何时使用工厂方法模式
工厂模式一般配合策略模式一起使用,当系统中有多种产品(策略),且每种产品有多个实例时,此时适合使用工厂模式:每种产品对应的工厂提供该产品不同实例的创建功能,从而避免调用方和产品创建逻辑的耦合,完美符合迪米特法则(最少知道原则)。
愉快地使用工厂方法模式
背景
在平常开发中,我们经常会在 Spring 中实现诸如这样的功能:收集某一类具有共同特征的 Bean(都实现了某个接口或者都打上了某个注解等),然后放入容器中(一般是 Map),使用的时候根据 Bean 的标识,来获取到对应的 Bean。比如我之前文章中的 通过表单标识获得表单对应提交处理器的 FormDataHandlerFactory:
1 | typescript复制代码@Componentpublic class FormDataHandlerFactory { |
通过表单项类型获得表单项转换器的 FormItemConverterFactory:
1 | typescript复制代码@Componentpublic class FormItemConverterFactory { |
在我见过的系统中,看到过非常多类似的代码,每次需要这样的功能,就是定义一个新的 XxxFactory,甚至还有直接在调用者里面直接写上这些获取对应 Bean 的代码,直接违反 单一原则。在这个时候,其实我们已经趋近于使用工厂方法模式,我们更倾向于称这种 XxxFactory 为简单工厂。不停地使用这种简单工厂的问题在于会导致 重复的代码,因而也就自然而然的违背了 DRY 原则(Don’t Repeat Yourself)。虽然重复的代码并不多,但是对于我们 Programmer 来说,写重复的代码无异于往我们脸上吐唾沫 —— 是可忍,孰不可忍!
所以接下来基于上面这个场景,我分享一下我目前基于 Spring 实现工厂方法模式的 “最佳套路”(如果你有更好的套路,欢迎赐教和讨论哦)~
方案
其实设计模式的核心就在于,找出变化的部分,然后对变化进行抽象和封装,从而使得代码能够满足面向对象的基本原则。对于工厂方法模式来说,变化的是产品、工厂,因而我们可以先定义出抽象的产品和抽象的工厂。
抽象的产品(策略):
1 | csharp复制代码public interface Strategy<T> { |
每个产品必须实现 Strategy 接口,代表每个产品必须有一个唯一的标识。
抽象的策略工厂:
1 | java复制代码public abstract class StrategyFactory<T, S extends Strategy<T>> implements InitializingBean, ApplicationContextAware { |
Spring 容器在启动的时候,会去扫描工厂指定的类型(Class < S >)的 Bean,并将其注册到工厂中(加入到 strategyMap)。所以对于工厂中产品的生产过程,借助 Spring,我们躺好就行。
接下来基于我们的抽象产品和抽象工厂,我们重构上面的两个 Factory:
通过表单标识获得表单对应提交处理器的 FormDataHandlerFactory
1 | scala复制代码@Componentpublic class FormDataHandlerFactory extends StrategyFactory<String, FormDataHandler> { |
FormDataHandlerFactory 只需要指定一下其产品类型为 FormDataHandler。当然,FormDataHandler 我们也需要改造一下:
1 | typescript复制代码public interface FormDataHandler extends Strategy<String> { |
通过表单项类型获得表单项转换器的 FormItemConverterFactory
1 | scala复制代码@Componentpublic class FormItemConverterFactory extends StrategyFactory<FormItemTypeEnum, FormItemConverter> { |
此时,FormItemConverterFactory 也只需要指定一下产品的类型,不再会写重复代码。同理,需要改造一下 FormItemConverter:
1 | csharp复制代码public interface FormItemConverter extends Strategy<FormItemTypeEnum> { |
如果这个时候新加一个 通过列表标识获得列表数据拉取器的 ListDataFetcherFactory,那么首先定义出获取列表数据的接口(产品):
1 | typescript复制代码public interface ListDataFetcher extends Strategy<String> { CommonResponse<JSONObject> fetchData(ListDataFetchRequest request);} |
然后再实现 ListDataFetcherFactory(工厂):
1 | scala复制代码@Componentpublic class ListDataFetcherFactory extends StrategyFactory<String, ListDataFetcher> { |
通过抽象产品 Strategy 和抽象工厂 StrategyFactory,我们的代码完美符合了 DRY 原则。
优化
借助反射
借助反射,我们还可以使得工厂代码变得更加简单:因为如果父类包含泛型参数,且子类对泛型参数进行了具体化,那么这个具体化的泛型类型,可在运行时获取到。基于这个特性,我们可以改造 StrategyFactory:
1 | scala复制代码public abstract class StrategyFactory<T, S extends Strategy<T>> implements InitializingBean, ApplicationContextAware { |
那么上面三个 Factory 写起来就更简单了:
1 | java复制代码@Componentpublic class FormDataHandlerFactory extends StrategyFactory<String, FormDataHandler> {} |
1 | scala复制代码@Componentpublic class FormItemConverterFactory extends StrategyFactory<FormItemTypeEnum, FormItemConverter> {} |
`- \
1 | scala复制代码@Componentpublic class ListDataFetcherFactory extends StrategyFactory<String, ListDataFetcher> {} |
组合优先于继承
上述的方案是通过继承,并借助泛型的反射功能,由子类来指定策略( S getStrategyType)的类型。如果工厂类型较多,那么每次新加一个工厂类,容易导致 “类爆炸”。对于上述的方案,变化的部分就是策略的类型,除了继承,我们还可以通过组合来解决这个变化。修改我们的 StrategyFactory:
1 | java复制代码public class StrategyFactory<T, S extends Strategy<T>> implements InitializingBean, ApplicationContextAware { |
此时 StrategyFactory 不再是抽象类,并且为 StrategyFactory 引入一个新的属性 strategyType,并且在构造 StrategyFactory 就必须设置当前工厂中的策略(产品)类型。那么对于 FormDataHandlerFactory、FormItemConverterFactory 和 ListDataFetcherFactory,我们不需要再通过继承产生,直接通过配置进行组合即可:
1 | csharp复制代码@Configurationpublic class FactoryConfig { |
全域营销团队
战斗在阿里电商的核心地带,负责连接供需两端,支持电商营销领域的各类产品、平台和解决方案,其中包括聚划算、百亿补贴、天猫U先、天猫小黑盒、天猫新品孵化、品牌号等重量级业务。我们深度参与双11、618、99划算节等年度大促,不断挑战技术的极限!我们致力于打造幸福感极强的技术团队,有深耕电商精研技术的老司机,也有朝气蓬勃的小萌新,更有可颜可甜的小姐姐,期待具有好奇心和思考力的你的加入!
本文转载自: 掘金