Java泛型实践：统一适配Document与BasicDBObject的递归方法改造

你编写的泛型方法存在两个核心问题，直接导致编译失败：

• 无边界泛型<T>的默认上界是java.lang.Object，编译器在编译阶段只能识别Object类自带的方法，完全不认识你代码里调用的getString()、get()方法，自然会抛出“找不到符号”的编译错误。
• 代码块中重复定义了两次同名变量rules（分别声明为ArrayList<BasicDBObject>和ArrayList<Document>），违反Java变量重复定义的语法规则。
• 不要尝试写类似<T extends Document, BasicDBObject>的联合上界，Java语法不支持同时绑定两个平级类作为泛型上界，会直接触发编译错误。

首先梳理两个目标类的公共能力：

• MongoDB驱动中的Document和BasicDBObject都是实现了Map<String, Object>接口的文档结构类，都支持按key存储、读取嵌套值
• 二者的嵌套规则列表存储的都是同类型的文档对象，结构完全一致
  基于这个公共特性，可以给泛型增加合适的上界约束，让编译器识别到T类型具备需要的操作能力，同时保留递归处理嵌套结构的逻辑，完全消除两个重载方法的重复代码。

推荐实现代码 #

public <T extends Map<String, Object>> String convertToRules(T rulesObj) {
    final StringBuilder expressionBuilder = new StringBuilder("${");
    
    // 从Map中读取condition值，等价于原实现中的rulesObj.getString("condition")
    Object conditionValue = rulesObj.get("condition");
    if (conditionValue != null) {
        String condition = conditionValue.toString();
        Object rulesRaw = rulesObj.get("rules");
        
        // 判断嵌套列表存在时做递归处理
        if (rulesRaw instanceof List) {
            List<?> ruleList = (List<?>) rulesRaw;
            ruleList.forEach(rule -> {
                // 原有业务处理逻辑
                expressionBuilder.append(convertToRules((T) rule));
            });
        }
    }
    
    // 原有字符串拼接逻辑
    return expressionBuilder.append("}").toString();
}

实现说明 #

• 泛型上界<T extends Map<String, Object>>明确告诉编译器，T一定是支持get()方法的Map实现类，Document和BasicDBObject本身就满足这个约束，传入时不需要额外适配
• 把原来调用类内置的getString()逻辑替换为从Map取值后手动转字符串，和两个类原生的getString()方法行为完全一致
• 嵌套列表处理时增加instanceof List的判断，避免非列表类型的字段值触发运行时类型转换异常
• 递归调用时自动匹配T类型，不需要为嵌套的Document/BasicDBObject元素单独写重载逻辑

如果觉得手动转字符串的写法和原类内置的getString()方法有语义差异，可以通过函数式抽象把两个类的取值逻辑注入，不过这种方式改动量更大，对于当前的重复代码消除场景，上面的Map上界实现已经完全满足需求。

内容的提问来源于stack exchange，提问作者Srikar