SpringMVC之RequestMappingInfo类建造者模式使用

Posted 2021-10-21 敲代码的小小酥

前言

RequestMappingInfo类是存储request与handler对应关系详情的类。该类是典型的建造者模式，下面我们通过源码分析该类为何使用以及如何使用的建造者模式。

为何使用建造者模式

我们看RequestMappingInfo的成员属性有哪些:

    private final String name;

	private final PatternsRequestCondition patternsCondition;

	private final RequestMethodsRequestCondition methodsCondition;

	private final ParamsRequestCondition paramsCondition;

	private final HeadersRequestCondition headersCondition;

	private final ConsumesRequestCondition consumesCondition;

	private final ProducesRequestCondition producesCondition;

	private final RequestConditionHolder customConditionHolder;

可见有8个成员属性，除了name属性外，其他属性都是存储Request需要满足的条件。
我们再看其构造方法:

public RequestMappingInfo(@Nullable PatternsRequestCondition patterns,
			@Nullable RequestMethodsRequestCondition methods, @Nullable ParamsRequestCondition params,
			@Nullable HeadersRequestCondition headers, @Nullable ConsumesRequestCondition consumes,
			@Nullable ProducesRequestCondition produces, @Nullable RequestCondition<?> custom) {

		this(null, patterns, methods, params, headers, consumes, produces, custom);
	}

	/**
	 * Re-create a RequestMappingInfo with the given custom request condition.
	 */
	public RequestMappingInfo(RequestMappingInfo info, @Nullable RequestCondition<?> customRequestCondition) {
		this(info.name, info.patternsCondition, info.methodsCondition, info.paramsCondition, info.headersCondition,
				info.consumesCondition, info.producesCondition, customRequestCondition);
	}

可以看到，该类没有无参构造，有参构造中，含有大量的参数，这让该类的初始化操作变得复杂。针对这种情况，采用建造者设计模式，再合适不过了。

如何使用建造者设计模式

设计模式之建造者模式(BuilderPattern)讲了建造者模式，我们来找到建造者模式中的几个角色。

抽象建造者:

public interface Builder {

		/**
		 * Set the path patterns.
		 */
		Builder paths(String... paths);

		/**
		 * Set the request method conditions.
		 */
		Builder methods(RequestMethod... methods);

		/**
		 * Set the request param conditions.
		 */
		Builder params(String... params);

		/**
		 * Set the header conditions.
		 * <p>By default this is not set.
		 */
		Builder headers(String... headers);

		/**
		 * Set the consumes conditions.
		 */
		Builder consumes(String... consumes);

		/**
		 * Set the produces conditions.
		 */
		Builder produces(String... produces);

		/**
		 * Set the mapping name.
		 */
		Builder mappingName(String name);

		/**
		 * Set a custom condition to use.
		 */
		Builder customCondition(RequestCondition<?> condition);

		/**
		 * Provide additional configuration needed for request mapping purposes.
		 */
		Builder options(BuilderConfiguration options);

		/**
		 * Build the RequestMappingInfo.
		 */
		RequestMappingInfo build();
	}

在RequestMappingInfo类的内部，定义了Builder接口作为抽象建造者角色，类中定义内部接口，也是一个比较新颖的操作，可以借鉴。把建造者定义在类的内部，其实完全没必要在定义抽象的建造者，但是Spring创建了，可见Spring的严谨性。

抽象建造者定义了构造各个组件的方法，返回值都是Builder对象。此外还 定义了build方法，获得RequestMappingInfo对象。标准的建造者模式的应用。

具体建造者:
DefaultBuilder内部类，是对Builder接口的实现，我们不再贴其源码。

产品角色:
产品角色就是RequestMappingInfo类本身，构建对象也是RequestMappingInfo。所以，RequestMappingInfo是在类的内部，进行了一番构造者模式的应用。这种思路，我们也可以进行借鉴。

导演角色:
没有定义导演类角色。