1.情景展示
请求入参：
这是一个对外提供的请求总入口，入参interfaceMethod对应不同的接口名称，具体的接口请求参数封装到xcParams里面。
对外只提供这一个接口，而不是不同接口提供不同地址，这样一来，无论是接口提供方还是接口调用方只要遵循这种规范，就可以完成不同接口的调用，也利于后期接口的启用、禁用、扩展新接口，提高系统的可维护性。
像这样，用实体类接收到请求入参，获取将要调取的接口方法，根据不同接口名称匹配调用不同的业务实现类进行业务处理。
2.现状分析
在实际开发过程中，公司与公司之间或者公司内部项目与项目之间往往会存在这种需求，公司A提供接口，公司B调用接口，如果是多个接口，那么就可以像上面那样搞一个总入口：
使用switch判断具体需要调用哪一个接口，以及负责处理的业务实现类就可以了。
以上的代码是完全没有问题的，已经满足了实际业务需要，这种入门级的代码，基本不要动什么脑子；
但是，如果我们想要使用高逼格的代码实现这种功能，能够让我们用更多java知识应用到实际开发过程中，学以致用，使自己的能力得到升华，换句话说就是：想装X，请欣赏下面的高逼格代码。
（其实，对于产品来说，不管你是低级代码还是高级代码实现，只要能满足产品需求就是OK的，这一点我们一定要摆好自己位置，不能沾沾自喜）
3.高级代码实现
先看效果
请求入参使用了泛型控制，不同接口自动映射到对应的实体类去接收（上图）
调对应接口时，一行代码搞定，无需手动加判断该调哪个业务实现类。
想实现这种效果，就继续往下看哈。
用实体类接收请求入参是本文的重中之重，先来看一下
第一，注解@Getter、@Setter；
使用的是lombok插件，其作用是生成私有属性的Get、Set方法，不想用或者没有的，自己手动生成替代就可以了（类的属性私有化，再对外提供Get和Set方法，其实就是java三大特性之一：封装）。
第二，注解@ApiModelProperty；
对请求参数进行介绍，使用的是knife4j，为接口提供的API文档，最终效果如下图所示：
这样一来，接口的请求参数、响应参数都有详细介绍，与别人对接接口的时候再也不用一遍一遍的跟不同的人解释了，把文档地址扔给他，清晰明了。
注意：这不是本文介绍的重点，心有余力的，见文末推荐文章。
第三，注解@JsonProperty；
反序列化：将json对象的key与实体类的指定属性对照起来，并完成赋值操作；
@JsonProperty，隶属于Jackson，springboot内部集成，请求入参转实体类默认使用的就是Jackson；
由于将请求参数与泛型进行映射，所以，每个属性都需要加上@JsonProperty注解进行对照。
第四，注解@NotBlank
字符串非空校验：只用在String上，表示传进来的值不能为null，而且调用trim()后，长度必须大于0，即：必须有实际字符。
说明：泛型无法使用注解进行非空校验，所以，上图中的注解@NotNull无效
第五，用枚举类来接收请求入参的其中一个参数值；
在这里，使用枚举类CzInterfaceEnum来接收请求参数InterfaceMethod的值，这个说法并不对，因为枚举类往往不止有一个属性，而InterfaceMethod却只有一个值，按正常逻辑来想，json是完全不能实现发序列化的。
这我们就不得不提及注解@JsonValue啦
被加上注解@JsonValue的属性，将会完成值的映射，也就是InterfaceMethod的值最终会被赋值到枚举类的interfaceName属性上，这样就没有一点问题了。
第六，往枚举类注入对象；
如果枚举类只有这一点点作用，那我们也不用废这么大劲用它接收，干脆用String类来接收岂不方便？
如果这样想，就大错特错了，再来回想一下，如果我们用String类来接收InterfaceMethod的值，那我们岂不是又回到了原点：后续还得用switch来判断，进而调用不同的业务实现类。
之所以想用枚举类来接收InterfaceMethod，是因为，这个时候，我们已经拿到了InterfaceMethod的值，换句话说，我们这个时候就已经知道，它调用的是哪个接口，该用哪个接口实现类来处理！
难点在于：如何往枚举类注入对象？
见文末推荐。
第七，不同接口的请求参数使用不同实体类接收；
通过注解@JsonTypeInfo和@JsonSubTypes结合实现
由最开始的时候，我们得知：不同的接口虽然请求参数不同，但都会塞到CzParams这个参数中，所以，我们就能根据参数InterfaceMethod来判断当前请求该用哪个请求实体类来接收；
所以，CzParams的类型只能用泛型来接收（只有在运行调用的时候，才能知道它是谁）；
这样一来，请求实体类只需继承抽象类CzRequestParams，并在该父类中设置@JsonSubType.Type注解即可。
如此，就能实现刚开始提到的效果；
对于高频接口，还可以开启多线程，解决并发问题（本文未做展示）。
4.多态的另一种用法
2020-12-15
关于用泛型接收类的方式，其实也是可以去掉的，只是，可能会让看代码的人一脸懵逼。
上面说的很清楚，这个地方用的是泛型，并在class类上用了泛型限定<T extends CzRequestParams>，这样方便其它人员维护，看到立马就知道实际接收参数的是CzRequestParams的子类。
既然是子类，那我们何不用的干脆一点？
把泛型干掉，直接用父类接收完事（向上泛型），实际负责接收的还是那些子类。
5.嵌套实体类校验不生效问题
2020-12-16
使用@Valid或@Validator注解进行相关检验时，会造成嵌套类上相关校验不生效的问题（嵌套验证），比如：
CzRequestDto类能够使用注解进行校验，这没有一点问题。
问题是：CzRequestDto类里又使用其他实体类接收请求参数，例如：上图中的泛型，它对应的其中一个实体类是下面这个类，
这就是所谓的嵌套。
在这个类里面，使用参数校验注解，不会生效。
如何解决这个问题？
这个问题困扰了我很久，其实很简单，在嵌套实体类的地方，再次声明校验注解就完事了。
写在最后
哪位大佬如若发现文章存在纰漏之处或需要补充更多内容，欢迎留言！！！