如何正确实现基于泛型对象的工厂方法？Java泛型擦除问题求解

嘿，这个问题我之前踩过不少坑——Java的泛型擦除真的是个让人挠头的家伙！针对你这种「接收泛型超类型Shape的实例，生成对应另一种超类型B的实例」的需求，行业里有几种非常成熟的标准实现方式，我结合你提到的Shape层级给你拆解清楚。

1. 传递Class令牌（最常用的标准方案） #

泛型擦除会让JVM在运行时丢失泛型类型信息，所以最直接的解决办法就是显式传递Class对象来保留类型标识。我们结合你的Shape层级，假设超类型B是ShapeRenderer（负责渲染Shape的类），来看具体实现：

// 先补全你的Shape层级示例
abstract class Shape<T extends Shape<T>> {
    private String userFriendlyShapeName = "not set";
    public abstract String getArea();
    // 省略其他方法
}

class Circle extends Shape<Circle> {
    private double radius;
    @Override
    public String getArea() {
        return String.valueOf(Math.PI * radius * radius);
    }
}

class Square extends Shape<Square> {
    private double side;
    @Override
    public String getArea() {
        return String.valueOf(side * side);
    }
}

// 超类型B的层级：ShapeRenderer
abstract class ShapeRenderer<T extends Shape<T>> {
    public abstract String render(T shape);
}

class CircleRenderer extends ShapeRenderer<Circle> {
    @Override
    public String render(Circle shape) {
        return "渲染圆形，面积：" + shape.getArea();
    }
}

class SquareRenderer extends ShapeRenderer<Square> {
    @Override
    public String render(Square shape) {
        return "渲染正方形，面积：" + shape.getArea();
    }
}

// 核心工厂类
class ShapeRendererFactory {
    // 基础方法：接收Class令牌创建对应Renderer
    @SuppressWarnings("unchecked")
    public static <T extends Shape<T>> ShapeRenderer<T> createRenderer(Class<T> shapeClass) {
        if (shapeClass == Circle.class) {
            return (ShapeRenderer<T>) new CircleRenderer();
        } else if (shapeClass == Square.class) {
            return (ShapeRenderer<T>) new SquareRenderer();
        }
        throw new IllegalArgumentException("不支持的形状类型：" + shapeClass.getName());
    }

    // 方便调用的重载：直接从Shape实例获取Class
    public static <T extends Shape<T>> ShapeRenderer<T> createRenderer(T shape) {
        return createRenderer((Class<T>) shape.getClass());
    }
}

方案优缺点 #

• 优点：简单直接，是Java社区处理泛型擦除的「标准操作」，可读性高，维护成本低。
• 注意点：如果存在子类继承（比如ColorCircle extends Circle），shape.getClass()会返回ColorCircle.class，此时需要在工厂里判断父类类型（比如用shape instanceof Circle），或者提前注册子类的映射。

2. 注册式工厂（扩展性优先方案） #

如果你的Shape子类会频繁新增，硬写if-else会导致工厂类越来越臃肿，这时候可以用注册式工厂，提前把「Shape类型-对应B类型」的映射存入Map，需要时直接取出：

class ShapeRendererFactory {
    // 存储类型与Renderer的映射
    private static final Map<Class<? extends Shape<?>>, ShapeRenderer<?>> RENDERER_MAP = new HashMap<>();

    // 静态代码块完成初始注册
    static {
        RENDERER_MAP.put(Circle.class, new CircleRenderer());
        RENDERER_MAP.put(Square.class, new SquareRenderer());
    }

    // 支持动态注册新的Shape类型
    public static <T extends Shape<T>> void registerRenderer(Class<T> shapeClass, ShapeRenderer<T> renderer) {
        RENDERER_MAP.put(shapeClass, renderer);
    }

    @SuppressWarnings("unchecked")
    public static <T extends Shape<T>> ShapeRenderer<T> createRenderer(T shape) {
        ShapeRenderer<T> renderer = (ShapeRenderer<T>) RENDERER_MAP.get(shape.getClass());
        if (renderer == null) {
            throw new IllegalArgumentException("未找到对应形状的渲染器：" + shape.getClass().getName());
        }
        return renderer;
    }
}

方案优缺点 #

• 优点：符合「开闭原则」，新增Shape子类只需要调用registerRenderer注册，无需修改工厂核心逻辑，扩展性拉满。
• 注意点：同样要处理子类继承的情况，如果想让子类复用父类的B实例，可以在获取映射时向上遍历父类类型查找。

3. 泛型类型令牌（避免显式传Class的方案） #

如果你不想显式传递Class对象，可以用TypeToken来保留编译时的泛型信息（纯Java可以自己模拟，或者用Guava的TypeToken工具类）：

// 纯Java实现的TypeToken（简化版）
abstract class TypeToken<T> {
    protected final Type type;

    protected TypeToken() {
        Type superclass = getClass().getGenericSuperclass();
        this.type = ((ParameterizedType) superclass).getActualTypeArguments()[0];
    }

    public Type getType() {
        return type;
    }
}

// 工厂扩展支持TypeToken
class ShapeRendererFactory {
    // ... 保留之前的方法

    @SuppressWarnings("unchecked")
    public static <T extends Shape<T>> ShapeRenderer<T> createRenderer(TypeToken<T> typeToken) {
        Class<T> shapeClass = (Class<T>) ((Class<?>) typeToken.getType());
        return createRenderer(shapeClass);
    }
}

// 调用方式
ShapeRenderer<Circle> circleRenderer = ShapeRendererFactory.createRenderer(new TypeToken<Circle>() {});

方案优缺点 #

• 优点：无需显式传递Class，通过匿名内部类保留泛型类型信息，适合对代码简洁性要求高的场景。
• 缺点：纯Java实现的TypeToken需要处理很多边界情况（比如嵌套泛型），如果项目依赖Guava，直接用它的TypeToken会更省心。

额外注意事项 #

• 泛型边界优化：你的Shape类定义abstract class Shape<T extends Shape>建议改成abstract class Shape<T extends Shape<T>>，这样能避免泛型擦除后出现不必要的类型转换警告，让类型约束更严谨。
• 类型转换警告：工厂里的@SuppressWarnings("unchecked")是正常的，只要你能保证类型映射的正确性，这个警告是安全的。
• 运行时类型：哪怕是泛型方法创建的Shape实例，getClass()依然能拿到实际的运行时类型，因为泛型擦除只擦除类定义的泛型参数，实例的实际类型是保留的。

总的来说，传递Class令牌的工厂是最通用的标准实现，如果你需要更好的扩展性就选注册式工厂，不想显式传Class可以用TypeToken方案，根据你的项目复杂度选择即可。

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