背景
在开发过程中，如果第三方接口参数的命名遵循肯定的标准，我方在封装申请体时会比拟不便和整洁，通常不须要过多的正文。然而如果第三方接口的参数命名十分随便呢？咱们晓得，如果是POST 申请，咱们能够应用 JSONField 。但如果是让咱们本人不依赖 fastjson 来实现一个GET申请的字符串拼接呢？
比方：
/api/addUser?NAME=xiaoguaiguai&agenumber=78&sex_flag=0&ji_Guan=西南那旮它揉合了多种命名规定并且还蕴含拼音，这个时候你应该如何保障本人的代码是整洁的呢？
1.定义属性注解
因为属性对应的参数名称十分随便，咱们筹备手动记录它，这样呢，咱们就须要一个注解：
import java.lang.annotation.*;@Retention(RetentionPolicy.RUNTIME)@Target(value={ElementType.FIELD})@Documented@Inheritedpublic @interface ThirdApiParamName { /** * 参数名称 * * @return */ String value();}2. 对应参数信息体增加属性注解
注解应用时非常简单，比方咱们有一个UserAddDTO.class，间接进行标记。
@Datapublic class UserAddDTO{ /** * 用户名称 */ @ThirdApiParamName("NAME") private String name; /** * 用户年龄 */ @ThirdApiParamName("agenumber") private int age; /** * 性别标记 * 0：女 * 1：男 */ @ThirdApiParamName("sex_flag") private int sexFlag; /** * 籍贯 */ @ThirdApiParamName("ji_Guan") private String nativePlace;} 这样写有什么益处呢？如果另外一个人，从日志看到了打印的申请的 url 字符串，发现了一个诡异的参数叫agenumber，他就开始Ctrl+Shift+F搜寻，正好发现了这个类，一看你的正文，他就能明确：啊，原来是年龄，他把两个单词写一块了。
3.Java反射解析注解
上面咱们应用反射机制，获取到对应的属性上的注解中填写的值以及属性的值，进行拼接。这一部分咱们能够写在工具类里，当然如果你DDD，你能够有本人的考量，我这里只给出函数体：
public static String fulfilledUrlWithParams(String urlPrefix, Object paramObject) { try { Class<?> aClass = paramObject.getClass(); Field[] declaredFields = aClass.getDeclaredFields(); StringBuilder stringBuffer = new StringBuilder(urlPrefix); stringBuffer.append("?"); StringJoiner paramStringJoiner = new StringJoiner("&"); for (Field declaredField : declaredFields) { // 对应每个属性，获取它对应的参数的名称 declaredField.setAccessible(true); Object valueObj = declaredField.get(paramObject); if (valueObj == null || StringUtils.isBlank(valueObj.toString())) { continue; } ThirdApiParamName paramName= declaredField.getAnnotation(ThirdApiParamName.class); if (paramName== null) { continue; } paramStringJoiner.add(paramName.value() + "=" + valueObj); } stringBuffer.append(paramStringJoiner.toString()); return stringBuffer.toString(); } catch (Exception e) { e.printStackTrace(); return ""; } }这样，咱们就把一个毫无命名法则的第三方接口参数规范化了。这样，咱们在封装好了整个申请服务后，开发组外部就是用咱们本人写的服务了，而不是各自去面对第三方凌乱的接口参数。
其实这个设计并不难想到，只有你相熟门面模式、代理模式、适配器模式，你会很天然想到要增加一个中间层，以屏蔽一些麻烦的细节。其实，编程中波及到设计相干的内容，大部分都是中间层的艺术。
思考题
接下来，留一个思考题给每一位读者：
在你的我的项目中，如果是遇到共事之间的接口调用，对方参数命名不标准，你应该怎么做呢？
欢送你在评论区留言，和其余读者进行探讨。