import com.fasterxml.jackson.databind.DeserializationFeature;import com.fasterxml.jackson.databind.ObjectMapper;import lombok.extern.slf4j.Slf4j;import org.apache.commons.collections.CollectionUtils;
import java.util.*;java
/** * Map 工具类 * * @author D瓜哥 · https://www.diguage.com */@Slf4jpublic class MapUtils {    private static final ObjectMapper MAPPER = new ObjectMapper();
    static {        MAPPER.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);    }
    /**     * 将 Map 转换成指定类型的对象     *     * @author D瓜哥 · https://www.diguage.com     */    public static  T convertToObject(Map data, Class<T> clazz) {        try {            T result = MAPPER.convertValue(data, MAPPER.getTypeFactory().constructType(clazz));            if (log.isInfoEnabled()) {                log.info("converted {} to a {} object: {}",                        JsonUtils.toJson(data), clazz.getSimpleName(), JsonUtils.toJson(result));            }            return result;        } catch (Exception e) {            log.error("converting failed! data: {}, class: {}",                    JsonUtils.toJson(data), clazz.getSimpleName(), e);        }        return null;    }
    /**     * 将 Map 转换成指定类型的对象     *     * @author D瓜哥 · https://www.diguage.com     */    public static  List convertToObjects(List        if (CollectionUtils.isEmpty(datas) || Objects.isNull(clazz)) {            return Collections.emptyList();        }        List result = new ArrayList<>(datas.size());        if (CollectionUtils.isNotEmpty(datas)) {            for (Map data : datas) {                T t = convertToObject(data, clazz);                result.add(t);            }        }        return result;    }}

现在，很多对外暴露接口的定义是，接口定义放在一个模块中；模型定义在一个模块中；有些工具类又定义在一个模块中。接口依赖模型模块；模型模块又依赖工具类模块；而工具类依赖了一大堆外部依赖。个人觉得这是一个非常不好的实践。会导致很多不必要的依赖被间接引入到了接口使用方的系统中，无形中增加很多维护成本。

推荐的一个实践是：将接口和模型定义放在一个模块中，对外暴露也只需要这一个模块即可。接口使用方只需要引入这一个依赖。避免引入很多无用的其他外部依赖。如果模型需要依赖一些公共的父类，可以考虑将这些单独定义在一个模块中，这个模块只保存多个系统依赖的公共类，并且剔除掉一些工具类的定义，这样就可以保证接口依赖的纯净性。如果其他系统需要工具类，让其明确去引入，而不是被动依赖。

对于前面《 对于状态值常量，优先在接口参数类或者返回值类中定义》（ https://www.diguage.com/post/tips-for-interface-maintainability/#constant-definition ） 中提到了“如果状态值很多，可以考虑单独抽取成一个常量类或者枚举类。” 这里存在一种情况需要特别说明，状态值的定义需要在本系统的业务模块的代码中使用，可以将接口的依赖加入到改业务模块的依赖中，而不是反过来。为什么会这样的操作？一个核心思想是保持对外暴露接口的纯净性。这样既可以减少状态定义的重复性，又可以减少接口的外部依赖。

观察很多系统，尤其是一些以业务为核心的系统的对外暴露接口，很多接口是大而全的接口，一个接口就可以把指定数据的所有信息全部返回出去。这样，很多字段需要去识别，也要在众多字段中区筛选出来符合自己要求的数据，无形中浪费了很多心智，不利于维护。

在做接口开发时，一定要做一个“吝啬的守财奴”。把数据当做财富一样守护，对外只提供必要的数据，做到“够用就行”。

这一点不仅仅是维护上的考虑，还有数据传输效率的点。在其他条件相同的情况下，更小的数据，无论是机器处理效率，还是传输效率，都会更快更高。

关于传输效率上的一些思考，结合《 Hessian、Msgpack 和 JSON 实例对比》（ https://www.diguage.com/post/hessian-vs-msgpack-vs-json/ ） 以及 “Hessian 协议解释与实战” 等文章来看，有几个原则值得重视的：

1. 优先使用 boolean 型；

2. boolean 型满足不了，次优选择 int 整型数据；再次可以考虑 long 型；

3. 日期优先使用内置的日期类型（含 Java Time API 类型），而不是格式化成字符串。

4. 对于以上类型不满足，则选择使用字符串。

5. 集合类型，链表优先使用 ArrayList，也可以考虑使用 Iterator；哈希优先使用 HashMap；