Spring Boot模板方法泛型报错及PDFGenerator接口使用疑问

1. 修复dto.getName()报错的方案 #

不想让DTO继承父类的话，用接口约束泛型是更合适的方案——接口是行为契约，不会给DTO强加不必要的继承关系：

步骤1：定义行为接口 #

创建一个仅包含getName()方法的接口，标记所有具备“获取名称”能力的DTO：

public interface HasName {
    String getName();
}

步骤2：让DTO实现接口 #

修改BrandDTO和ProductDTO，实现该接口（仅需实现getName()方法，不侵入原有业务逻辑）：

// BrandDTO示例
public class BrandDTO implements HasName {
    private String brandName;

    @Override
    public String getName() {
        return this.brandName;
    }

    // 原有getter/setter等方法
}

// ProductDTO示例
public class ProductDTO implements HasName {
    private String productName;

    @Override
    public String getName() {
        return this.productName;
    }

    // 原有方法
}

步骤3：约束抽象类泛型 #

修改AbstractPDFGenerator的泛型声明，让T必须实现HasName接口，编译器就能识别dto.getName()方法：

public abstract class AbstractPDFGenerator<T extends HasName> implements PDFGenerator {

    @Override
    public String createHtml(UUID uuid) {
        T dto = getDTO(uuid);

        Context context = new Context();        
        context.setVariable(getName(), dto.getName()); // 此处不再报错

        // ... 原有其他代码
    }

    // 原有抽象方法
    protected abstract T getDTO(UUID uuid);
    protected abstract String getName();
}

2. 是否需要保留PDFGenerator接口？ #

分场景判断：

• 需要保留：如果业务中有多态使用场景（比如统一注入PDFGenerator类型实例、批量处理不同PDF生成器），保留接口能遵循依赖倒置原则，让代码更灵活可扩展。
• 可以移除：如果接口仅作为抽象类的标记，没有任何地方直接依赖PDFGenerator（所有注入和调用都用具体子类或抽象父类），可直接移除，简化结构。

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