共计 2103 个字符,预计需要花费 6 分钟才能阅读完成。
背景
在开发过程中,如果第三方接口参数的命名遵循肯定的标准,我方在封装申请体时会比拟不便和整洁,通常不须要过多的正文。然而如果第三方接口的参数命名十分随便呢?咱们晓得,如果是 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
@Inherited
public @interface ThirdApiParamName {
/**
* 参数名称
*
* @return
*/
String value();}
2. 对应参数信息体增加属性注解
注解应用时非常简单,比方咱们有一个UserAddDTO.class
,间接进行标记。
@Data
public 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 "";
}
}
这样,咱们就把一个毫无命名法则的第三方接口参数规范化了。这样,咱们在封装好了整个申请服务后,开发组外部就是用咱们本人写的服务了,而不是各自去面对第三方凌乱的接口参数。
其实这个设计并不难想到,只有你相熟门面模式、代理模式、适配器模式,你会很天然想到要增加一个中间层,以屏蔽一些麻烦的细节。其实,编程中波及到设计相干的内容,大部分都是中间层的艺术。
思考题
接下来,留一个思考题给每一位读者:
在你的我的项目中,如果是遇到共事之间的接口调用,对方参数命名不标准,你应该怎么做呢?
欢送你在评论区留言,和其余读者进行探讨。