模板方法模式实现多类型邮件生成时如何避免传递Map参数

你可以通过给抽象模板类添加泛型参数的方式，彻底替换掉无类型约束的Map参数，同时保留模板方法模式统一流程骨架的优势，实现类型安全的参数传递。

核心改造思路 #

给抽象基类声明泛型参数，用来指定不同子类构建邮件时需要的上下文参数类型，把差异化的参数封装成专属的强类型上下文类，避免使用Map存值再强转的逻辑。

改造后的抽象基类代码如下：

public abstract class TemplateBuilder<T> {
    // 模板方法统一控制邮件生成的全流程，禁止子类重写整个流程
    public final Email buildEmail(T context) {
        // 公共前置逻辑：参数校验、初始化公共邮件头、设置统一发件人等
        checkContext(context);
        Email email = initCommonEmailPart();
        // 调用子类实现的自定义内容填充
        buildCustomContent(email, context);
        // 公共后置逻辑：添加统一页脚、退订入口、合规声明等
        addCommonFooter(email);
        return email;
    }

    // 子类必须实现的差异化构建逻辑
    protected abstract void buildCustomContent(Email email, T context);

    // 所有子类复用的公共逻辑
    private Email initCommonEmailPart() {
        Email email = new Email();
        email.setSender("no-reply@example.com");
        return email;
    }

    private void addCommonFooter(Email email) {
        // 拼接公共页脚内容
    }

    private void checkContext(T context) {
        if (context == null) {
            throw new IllegalArgumentException("邮件构建上下文不能为空");
        }
    }
}

具体子类实现方式 #

每一种类型的邮件，单独定义对应的上下文类，里面只放构建这类邮件需要的强类型字段，不需要兼容其他邮件类型的参数：

• 比如构建订单通知邮件时，先定义OrderEmailContext类，字段包含收件人信息、订单号、商品明细、下单时间等订单邮件专属内容，对应的builder继承基类时指定泛型为该上下文类：

// 订单邮件专属上下文，所有字段都是强类型
public class OrderEmailContext {
    private User recipient;
    private Order orderInfo;
    private List<OrderItem> itemList;

    // 构造函数、getter方法省略
}

public class OrderEmailBuilder extends TemplateBuilder<OrderEmailContext> {
    @Override
    protected void buildCustomContent(Email email, OrderEmailContext context) {
        // 直接获取强类型字段使用，不需要从Map中取值再强转
        email.setTo(context.getRecipient().getEmailAddress());
        email.setSubject("您的订单%s已确认".formatted(context.getOrderInfo().getOrderNo()));
        // 拼接订单详情邮件正文
    }
}

• 构建验证码邮件时，定义VerifyCodeEmailContext类，字段包含收件邮箱、验证码、过期时间即可，对应builder指定泛型为VerifyCodeEmailContext，和其他邮件类型的参数完全解耦。

方案优势 #

• 彻底移除了Map<String, Object>这类无类型约束的参数，所有参数在编译期就能做类型检查，不会出现key拼写错误、类型强转失败这类运行时异常
• 每个邮件类型的上下文类职责单一，需要什么字段就维护什么字段，不会出现大而全的参数类堆砌无关字段的问题
• 模板方法的公共流程逻辑完全收敛在抽象基类中，子类只需要关心自己的差异化内容，符合模板方法模式的设计初衷

如果有跨场景的公共参数需求，还可以通过接口抽象实现，比如给需要携带用户信息的上下文类统一实现IUserInfoProvider接口，基类的公共逻辑可以直接基于接口做统一处理，不需要感知具体的上下文类型。

不要为了强行统一方法签名就用Map作为通用参数，这种做法本质是绕开了语言的类型系统，把本该在编译期发现的问题全部推迟到运行时，后续维护成本极高。泛型+专属上下文类的方案，既保留了模板方法统一流程的能力，又给了子类足够的参数自由度，是这类场景的通用解法。

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