如何判断Class<FType>是否满足DataUtil的泛型约束？

因为Java泛型擦除的特性，直接从Class<FType>对象拿不到泛型的边界信息，但我们可以通过解析类实现的参数化类型接口来判断是否满足FType extends DataUtil<FType>的约束。

下面是一个实用的工具方法，核心逻辑是遍历类实现的所有接口，找到DataUtil的参数化类型实例，然后验证其实际类型参数是否为类自身：

public class TypeCheckUtil {
    public static boolean isValidDataUtilType(Class<?> clazz) {
        // 先检查当前类是否直接实现了泛型化的DataUtil接口
        for (Type iface : clazz.getGenericInterfaces()) {
            if (iface instanceof ParameterizedType parameterizedType) {
                Type rawType = parameterizedType.getRawType();
                // 确认接口的原始类型是DataUtil
                if (rawType == DataUtil.class) {
                    Type actualTypeArg = parameterizedType.getActualTypeArguments()[0];
                    // 自限定泛型要求实际类型参数就是类本身
                    if (actualTypeArg instanceof Class<?> actualClass) {
                        return actualClass == clazz;
                    }
                    // 处理泛型类的情况（如果你的POJO是泛型类，可能需要额外逻辑，不过一般POJO是具体类）
                    if (actualTypeArg instanceof TypeVariable<?>) {
                        return false;
                    }
                }
            }
        }
        // 递归检查父类是否继承了符合要求的DataUtil实现类
        Class<?> superClass = clazz.getSuperclass();
        if (superClass != null && !Object.class.equals(superClass)) {
            return isValidDataUtilType(superClass);
        }
        return false;
    }
}

方法说明 #

1. 遍历类实现的所有接口，筛选出ParameterizedType类型的接口（即带泛型参数的接口）。
2. 找到原始类型为DataUtil.class的参数化接口，提取其第一个泛型参数。
3. 验证这个泛型参数是否等于当前类本身——因为自限定泛型T extends DataUtil<T>要求T必须是实现接口的类自身。
4. 如果当前类没有直接实现，递归检查父类（处理继承了符合要求的类的情况）。

如果反射解析泛型的逻辑对你来说太繁琐，或者担心泛型擦除带来的边缘情况，这里有两个更简单的替代方案：

方案一：添加标记注解 #

定义一个运行时注解，专门标记符合DataUtil<T>自限定约束的POJO类，然后通过注解判断即可：

// 定义标记注解
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface DataUtilCompatible {}

// 在符合要求的POJO上添加注解
@DataUtilCompatible
public class MyPoJo implements DataUtil<MyPoJo> {
    // ... 类内容
}

判断逻辑就变得非常简单：

public static boolean isValidDataUtilType(Class<?> clazz) {
    return DataUtil.class.isAssignableFrom(clazz) 
        && clazz.isAnnotationPresent(DataUtilCompatible.class);
}

这个方案的优点是简单可靠，完全避免了反射解析泛型的复杂性；缺点是需要手动给每个符合要求的POJO添加注解，适合你自己维护POJO类的场景。

方案二：在接口中添加类型验证方法 #

在DataUtil接口中添加一个默认方法，让实现类返回自身的类型，然后通过这个方法验证泛型参数是否正确：

public interface DataUtil<T extends DataUtil<T>> {
    default T someDefaultFn() { 
        // 原方法逻辑
    }

    default Class<T> getSelfType() {
        // 反射解析当前类的DataUtil泛型参数
        for (Type type : this.getClass().getGenericInterfaces()) {
            if (type instanceof ParameterizedType pt) {
                if (pt.getRawType() == DataUtil.class) {
                    Type arg = pt.getActualTypeArguments()[0];
                    if (arg instanceof Class<?>) {
                        return (Class<T>) arg;
                    }
                }
            }
        }
        throw new IllegalStateException("Invalid DataUtil implementation: " + this.getClass().getName());
    }
}

判断时，先检查类是否实现了DataUtil，然后实例化（如果允许）并验证返回的类型是否为类自身：

public static <FType> boolean isValidDataUtilType(Class<FType> clazz) {
    if (!DataUtil.class.isAssignableFrom(clazz)) {
        return false;
    }
    try {
        // 尝试实例化类（需要无参构造）
        DataUtil<?> instance = (DataUtil<?>) clazz.getDeclaredConstructor().newInstance();
        return instance.getSelfType() == clazz;
    } catch (Exception e) {
        // 如果实例化失败（比如没有无参构造）， fallback到反射判断逻辑
        return TypeCheckUtil.isValidDataUtilType(clazz);
    }
}

这个方案的优点是把泛型验证逻辑封装在了接口内部，缺点是需要实例化对象（如果POJO没有无参构造会报错）。

内容的提问来源于stack exchange，提问作者Cường Vô Quốc