关于spring:4-上新了Spring全新一代类型转换机制

分享、成长，回绝浅藏辄止。关注公众号【BAT的乌托邦】，回复关键字专栏有Spring技术栈、中间件等小而美的原创专栏供以收费学习。本文已被 https://www.yourbatman.cn 收录。

✍前言

你好，我是YourBatman。
上篇文章 介绍完了Spring类型转换晚期应用的PropertyEditor具体介绍，对于PropertyEditor现存的材料其实还蛮少的，心愿这几篇文章能补救这块空白，奉献一份微薄之力。
如果你也吐槽过PropertyEditor不好用，那么本文将对会有帮忙。Spring自3.0版本开始自建了一套全新类型转换接口，这就是本文的次要内容，接下来逐渐开展。

阐明：Spring自3.0后笑傲群雄，进入大一统。Java从此步入Spring的时代

版本约定

• Spring Framework：5.3.1
• Spring Boot：2.4.0

✍注释

在理解新一代的转换接口之前，先思考一个问题：Spring为何要本人造一套轮子呢？ 一贯秉承不反复造轮子准则的Spring，不是无可奈何的话是不会去动别人奶酪的，毕竟互利共生能力短暂。类型转换，作为Spring框架的基石，扮演着异样重要的角色，因而对其可扩展性、可维护性、高效性均有很高要求。
基于此，咱们先来理解下PropertyEditor设计上到底有哪些缺点/有余（不能满足现代化需要），让Spring“被迫”走上了自建路线。

PropertyEditor设计缺点

前提阐明：本文指出它的设计缺点，只探讨把它当做类型转换器在转换场景下存在的一些缺点。

1. 职责不繁多：该接口有十分多的办法，但只用到2个而已
2. 类型不平安：setValue()办法入参是Object，getValue()返回值是Object，依赖于约定好的类型强转，不平安
3. 线程不平安：依赖于setValue()后getValue()，实例是线程不平安的
4. 语义不清晰：从语义上基本不能晓得它是用于类型转换的组件
5. 只能用于String类型：它只能进行String <-> 其它类型的转换，而非更灵便的Object <-> Object

PropertyEditor存在这五宗“罪”，让Spring决定本人设计一套全新API用于专门服务于类型转换，这就是本文题目所述：新一代类型转换Converter、ConverterFactory、GenericConverter。

对于PropertyEditor在Spring中的详情介绍，请参见文章：3. 搞定出工，PropertyEditor就到这

新一代类型转换

为了解决PropertyEditor作为类型转换形式的设计缺点，Spring 3.0版本从新设计了一套类型转换接口，有3个外围接口：

1. Converter<S, T>：Source -> Target类型转换接口，实用于1:1转换
2. ConverterFactory<S, R>：Source -> R类型转换接口，实用于1:N转换
3. GenericConverter：更为通用的类型转换接口，实用于N:N转换
4. 留神：就它没有泛型束缚，因为是通用

另外，还有一个条件接口ConditionalConverter，可跟下面3个接口搭配组合应用，提供前置条件判断验证。
这套接口，解决了PropertyEditor做类型转换存在的所有缺点，且具备十分高的灵活性和可扩展性。上面进入具体理解。

Converter

将源类型S转换为指标类型T。

@FunctionalInterfacepublic interface Converter<S, T> { T convert(S source);}

它是个函数式接口，接口定义非常简单。适宜1:1转换场景：能够将任意类型 转换为 任意类型。它的实现类十分多，局部截图如下：

值得注意的是：简直所有实现类的拜访权限都是default/private，只有少数几个是public公开的，上面我用代码示例来“近距离”感受一下。

代码示例

/** * Converter：1:1 */@Testpublic void test() { System.out.println("----------------StringToBooleanConverter---------------"); Converter<String, Boolean> converter = new StringToBooleanConverter(); // trueValues.add("true"); // trueValues.add("on"); // trueValues.add("yes"); // trueValues.add("1"); System.out.println(converter.convert("true")); System.out.println(converter.convert("1")); // falseValues.add("false"); // falseValues.add("off"); // falseValues.add("no"); // falseValues.add("0"); System.out.println(converter.convert("FalSe")); System.out.println(converter.convert("off")); // 留神：空串返回的是null System.out.println(converter.convert("")); System.out.println("----------------StringToCharsetConverter---------------"); Converter<String, Charset> converter2 = new StringToCharsetConverter(); // 两头横杠非必须，但强烈建议写上   不辨别大小写 System.out.println(converter2.convert("uTf-8")); System.out.println(converter2.convert("utF8"));}

运行程序，失常输入：

----------------StringToBooleanConverter---------------truetruefalsefalsenull----------------StringToCharsetConverter---------------UTF-8UTF-8

阐明：StringToBooleanConverter/StringToCharsetConverter拜访权限都是default，内部不可间接应用。此处为了做示例用到一个小技巧 -> 将Demo的报名调整为和转换器的一样，这样就能够间接拜访。
关注点：true/on/yes/1都能被正确转换为true的，且对于英文字母来说个别都不辨别大小写，减少了容错性（包含Charset的转换）。

有余

Converter用于解决1:1的任意类型转换，因而它必然存在一个有余：解决1:N转换问题须要写N遍，造成反复冗余代码。
譬如：输出是字符串，它能够转为任意数字类型，包含byte、short、int、long、double等等，如果用Converter来转换的话每个类型都得写个转换器，想想都麻烦有木有。
Spring早早就思考到了该场景，提供了相应的接口来解决，它就是ConverterFactory<S, R>。

ConverterFactory

从名称上看它代表一个转换工厂：能够将对象S转换为R的所有子类型，从而造成1:N的关系。

该接口形容为xxxFactory是十分适合的，很好的表白了1:N的关系

public interface ConverterFactory<S, R> { <T extends R> Converter<S, T> getConverter(Class<T> targetType);}

它同样也是个函数式接口。该接口的实现类并不多，Spring Framework共提供了5个内建实现（拜访权限全副为default）：

以StringToNumberConverterFactory为例看看实现的套路：

final class StringToNumberConverterFactory implements ConverterFactory<String, Number> { @Override public <T extends Number> Converter<String, T> getConverter(Class<T> targetType) { return new StringToNumber<T>(targetType); } // 公有外部类：实现Converter接口。用泛型边界束缚一类类型 private static final class StringToNumber<T extends Number> implements Converter<String, T> { private final Class<T> targetType; public StringToNumber(Class<T> targetType) { this.targetType = targetType; } @Override public T convert(String source) { if (source.isEmpty()) { return null; } return NumberUtils.parseNumber(source, this.targetType); } }}

由点知面，ConverterFactory作为Converter的工厂，对Converter进行包装，从而达到屏蔽外部实现的目标，对使用者敌对，这不正是工厂模式的长处么，合乎xxxFactory的语义。但你须要革除的是，工厂外部实现其实也是通过泛滥if else之类的去实现的，实质上并无差别。

代码示例

/** * ConverterFactory：1:N */@Testpublic void test2() { System.out.println("----------------StringToNumberConverterFactory---------------"); ConverterFactory<String, Number> converterFactory = new StringToNumberConverterFactory(); // 留神：这里不能写根本数据类型。如int.class将抛错 System.out.println(converterFactory.getConverter(Integer.class).convert("1").getClass()); System.out.println(converterFactory.getConverter(Double.class).convert("1.1").getClass()); System.out.println(converterFactory.getConverter(Byte.class).convert("0x11").getClass());}

运行程序，失常输入：

----------------StringToNumberConverterFactory---------------class java.lang.Integerclass java.lang.Doubleclass java.lang.Byte

关注点：数字类型的字符串，是能够被转换为任意Java中的数字类型的，String(1) -> Number(N)。这便就是ConverterFactory的功绩，它能解决这一类转换问题。

有余

既然有了1:1、1:N，天然就有N:N。比方汇合转换、数组转换、Map到Map的转换等等，这些N:N的场景，就须要借助下一个接口GenericConverter来实现。

GenericConverter

它是一个通用的转换接口，用于在两个或多个类型之间进行转换。相较于前两个，这是最灵便的SPI转换器接口，但也是最简单的。

public interface GenericConverter { Set<ConvertiblePair> getConvertibleTypes(); Object convert(Object source, TypeDescriptor sourceType, TypeDescriptor targetType); // 一般POJO final class ConvertiblePair { private final Class<?> sourceType; private final Class<?> targetType; }}

该接口并非函数式接口，尽管办法不多但稍显简单。现对呈现的几个类型做简略介绍：

• ConvertiblePair：保护sourceType和targetType的POJO

  • getConvertibleTypes()办法返回此Pair的Set汇合。由此也能看出该转换器是能够反对N:N的（大多数状况下只写一对值而已，也有写多对的）

• TypeDescriptor：类型形容。该类专用于Spring的类型转换场景，用于形容from or to的类型

  • 比独自的Type类型弱小，外部借助了ResolvableType来解决泛型议题

GenericConverter的内置实现也比拟多，局部截图如下：

ConditionalGenericConverter是GenericConverter和条件接口ConditionalConverter的组合，作用是在执行GenericConverter转换时减少一个前置条件判断办法。
转换器 | 形容 | 示例

阐明：分割线上面的4个转换器比拟非凡，字面上不好了解其理论作用，比拟“高级”。它们如果能被使用在日常工作中能够事半功弎，因而放在在下篇文章专门给你介绍
上面以CollectionToCollectionConverter为例剖析此转换器的“简单”之处：

final class CollectionToCollectionConverter implements ConditionalGenericConverter { private final ConversionService conversionService; public CollectionToCollectionConverter(ConversionService conversionService) { this.conversionService = conversionService; } // 汇合转汇合：如String汇合转为Integer汇合 @Override public Set<ConvertiblePair> getConvertibleTypes() { return Collections.singleton(new ConvertiblePair(Collection.class, Collection.class)); }}

这是惟一结构器，必须传入ConversionService：元素与元素之间的转换是依赖于conversionService转换服务去实现的，最终实现汇合到汇合的转换。

CollectionToCollectionConverter： @Override public boolean matches(TypeDescriptor sourceType, TypeDescriptor targetType) { return ConversionUtils.canConvertElements(sourceType.getElementTypeDescriptor(), targetType.getElementTypeDescriptor(), this.conversionService); }```判断是否转换的根据：汇合里的**元素与元素之间**是否可能转换，底层依赖于`ConversionService#canConvert()`这个API去实现判断。接下来再看**最简单**的转换方法：

CollectionToCollectionConverter：
@Override public Object convert(Object source, TypeDescriptor sourceType, TypeDescriptor targetType) { if (source == null) { return null; } Collection<?> sourceCollection = (Collection<?>) source;
// 判断：这些状况下，将不必执行后续转换动作了，间接返回即可
boolean copyRequired = !targetType.getType().isInstance(source); if (!copyRequired && sourceCollection.isEmpty()) { return source; } TypeDescriptor elementDesc = targetType.getElementTypeDescriptor(); if (elementDesc == null && !copyRequired) { return source; }
Collection<Object> target = CollectionFactory.createCollection(targetType.getType(), (elementDesc != null ? elementDesc.getType() : null), sourceCollection.size()); // 若指标类型没有指定泛型（没指定就是Object），不必遍历间接增加全副即可
if (elementDesc == null) { target.addAll(sourceCollection); } else { // 遍历：一个一个元素的转，工夫复杂度还是蛮高的
// 元素转元素委托给conversionService去实现
for (Object sourceElement : sourceCollection) { Object targetElement = this.conversionService.convert(sourceElement, sourceType.elementTypeDescriptor(sourceElement), elementDesc); target.add(targetElement); if (sourceElement != targetElement) { copyRequired = true; } } }
return (copyRequired ? target : source); }`
该转换步骤略微有点简单，我帮你屡分明后有这几个关键步骤：

1. 疾速返回：对于非凡状况，做疾速返回解决

   1. 若指标元素类型是源元素类型的子类型（或雷同），就没有转换的必要了（copyRequired = false）
   2. 若源汇合为空，或者指标汇合没指定泛型，也不须要做转换动作
   3. 源汇合为空，还转换个啥
   4. 指标汇合没指定泛型，那就是Object，因而能够接收所有，还转换个啥

2. 若没有触发疾速返回。给指标创立一个新汇合，而后把source的元素一个一个的放进新汇合里去，这里又分为两种解决case

3. 1. 若新汇合（指标汇合）没有指定泛型类型（那就是Object），就间接putAll即可，并不需要做类型转换
1. 若新汇合（指标汇合指定了泛型类型），就遍历源汇合委托conversionService.convert()对元素一个一个的转

代码示例

以CollectionToCollectionConverter做示范：List<String> -> Set<Integer>

@Testpublic void test3() { System.out.println("----------------CollectionToCollectionConverter---------------"); ConditionalGenericConverter conditionalGenericConverter = new CollectionToCollectionConverter(new DefaultConversionService()); // 将Collection转为Collection（留神：没有指定泛型类型哦） System.out.println(conditionalGenericConverter.getConvertibleTypes()); List<String> sourceList = Arrays.asList("1", "2", "2", "3", "4"); TypeDescriptor sourceTypeDesp = TypeDescriptor.collection(List.class, TypeDescriptor.valueOf(String.class)); TypeDescriptor targetTypeDesp = TypeDescriptor.collection(Set.class, TypeDescriptor.valueOf(Integer.class)); System.out.println(conditionalGenericConverter.matches(sourceTypeDesp, targetTypeDesp)); Object convert = conditionalGenericConverter.convert(sourceList, sourceTypeDesp, targetTypeDesp); System.out.println(convert.getClass()); System.out.println(convert);}

运行程序，失常输入：

[java.util.Collection -> java.util.Collection]trueclass java.util.LinkedHashSet[1, 2, 3, 4]

关注点：target最终应用的是LinkedHashSet来存储，这后果和CollectionFactory#createCollection该API的实现逻辑是相干（Set类型默认创立的是LinkedHashSet实例）。

有余

如果说它的长处是功能强大，可能解决简单类型的转换（PropertyEditor和前2个接口都只能转换单元素类型），那么毛病就是应用、自定义实现起来比较复杂。这不官网也给出了应用领导意见：在Converter/ConverterFactory接口可能满足条件的状况下，可不应用此接口就不应用。

ConditionalConverter

条件接口，@since 3.2。它能够为Converter、GenericConverter、ConverterFactory转换减少一个前置判断条件。

public interface ConditionalConverter { boolean matches(TypeDescriptor sourceType, TypeDescriptor targetType);}

该接口的实现，截图如下：

能够看到，只有通用转换器GenericConverter和它进行了合体。这也很容易了解，作为通用的转换器，加个前置判断将更加谨严和更平安。对于专用的转换器如Converter，它已明确规定了转换的类型，天然就不须要做前置判断喽。

✍总结

本文具体介绍了Spring新一代的类型转换接口，类型转换作为Spring的基石，其重要性可见一斑。
PropertyEditor作为Spring晚期应用“转换器”，因存在泛滥设计缺点自Spring 3.0起被新一代转换接口所取代，次要有：

1. Converter<S, T>：Source -> Target类型转换接口，实用于1:1转换
2. ConverterFactory<S, R>：Source -> R类型转换接口，实用于1:N转换
3. GenericConverter：更为通用的类型转换接口，实用于N:N转换

下篇文章将针对于GenericConverter的几个非凡实现撰专文为你解说，你也晓得做难事必有所得，做难事才有可能破局、破圈，欢送放弃关注。

✔✔✔举荐浏览✔✔✔

【Spring类型转换】系列：

• 1. 揭秘Spring类型转换 - 框架设计的基石
• 2. Spring晚期类型转换，基于PropertyEditor实现
• 3. 搞定出工，PropertyEditor就到这

【Jackson】系列：

• 1. 初识Jackson -- 世界上最好的JSON库
• 2. 妈呀，Jackson原来是这样写JSON的
• 3. 懂了这些，方敢在简历上说会用Jackson写JSON
• 4. JSON字符串是如何被解析的？JsonParser理解一下
• 5. JsonFactory工厂而已，还蛮有料，这是我没想到的
• 6. 二十不惑，ObjectMapper应用也不再蛊惑
• 7. Jackson用树模型解决JSON是必备技能，不信你看

【数据校验Bean Validation】系列：

• 1. 不吹不擂，第一篇就能晋升你对Bean Validation数据校验的认知
• 2. Bean Validation申明式校验办法的参数、返回值
• 3. 站在应用层面，Bean Validation这些标准接口你须要烂熟于胸
• 4. Validator校验器的五大外围组件，一个都不能少
• 5. Bean Validation申明式验证四大级别：字段、属性、容器元素、类
• 6. 自定义容器类型元素验证，类级别验证（多字段联结验证）

【新个性】系列：

• IntelliJ IDEA 2020.3正式公布，年度最初一个版本很讲武德
• IntelliJ IDEA 2020.2正式公布，诸多亮点总有几款能助你提效
• [IntelliJ IDEA 2020.1正式公布，你要的Almost都在这！]()
• Spring Framework 5.3.0正式公布，在云原生路上持续发力
• Spring Boot 2.4.0正式公布，全新的配置文件加载机制（不向下兼容）
• Spring扭转版本号命名规定：此举对非英语国家很敌对
• JDK15正式公布，划时代的ZGC同时发表转正

【程序人生】系列：

• 蚂蚁金服上市了，我不想致力了
• 如果程序员和产品经理都用凡尔赛文学对话......
• 程序人生 | 春风得意马蹄疾，一日看尽长安花

还有诸如【Spring配置类】【Spring-static】【Spring数据绑定】【Spring Cloud Netflix】【Feign】【Ribbon】【Hystrix】...更多原创专栏，关注BAT的乌托邦回复专栏二字即可全副获取，分享、成长，回绝浅藏辄止。

有些专栏已完结，有些正在连载中，期待你的关注、共同进步