java - 如何为需要不同渲染参数的不同类型的电子邮件构建电子邮件请求类？

Question

目前，我的通知请求是这样的:

public class EmailRequest{
  public enum EmailType{
    TYPE_1,
    TYPE_2,
    ...
  }
  EmailType emailType;
  String toAddress;
  EmailRenderer renderer;
}

其中 EmailRenderer 是一个接口(interface)

public interface EmailRenderer{
  EmailMessage render()
}

现在，每种类型的电子邮件都有渲染器接口(interface)的单独实现，并且每个实现都包含一些必须由客户端提供的渲染数据。对于每个实现，此数据可能不同。

示例:

public class Type1EmailRenderer implements EmailRenderer{
  String param1;
  String param2;
  @Override
  EmailMessage render(){
    //rendering logic using the params
  }
}

但是，对我来说，用户设置电子邮件类型和渲染器似乎也是多余的。选择渲染器应该会自动获取电子邮件类型。我应该如何重组请求以消除这种冗余？另外，我可以使用任何设计模式来向我的用户提供渲染器吗？

Answer 1

我的回答基于以下主张:抛开与编程相关的问题不谈，在人类逻辑层面上，如果我想发送电子邮件，我应该了解渲染器，这在我看来很奇怪。

据我了解，如果我有不同类型的电子邮件(您已将它们称为 TYPE_1 和 TYPE_2，为了更清楚起见，让我们提供更多“业务”名称，例如“dailyReport”或“advertisement”，您稍后会明白原因)我应该用我的数据(param1，param2)准备一个请求并发送它。我根本不应该关心渲染器，只要相同的电子邮件类型假设将使用相同类型的渲染器。

因此，可以说，类型“advertisement”具有强制参数 String topic 和可选参数 String targetAudience，并且类型“dailyReport”具有 IntegertotalUsersCount code> 和可选的 StringmostActiveUserName。

在这种情况下，我提出了一种主要基于 Builder 创建模式的混合方法:

  public class EmailRequestBuilder {

      private String toAddress;

      private EmailRequestBuilder(String to) {
          this.toAddress = to;
      }
      public static EmailRequestBuilder newEmailRequest(String to) {
          return new EmailRequestBuilder(to);
      } 

      public AdvertisementBuilder ofAdvertisementType(String topic) {
          return new AdvertisementBuilder(topic, this);
      }

      public DailyReportBuilder ofDailyReportType(Integer totalUsersCount) {
          return new DailyReportBuilder(totalUsersCount, this);
      }
      // all builders in the same package, hence package private build method,
      // concrete email type builders will call this method, I'll show at the end
      EmailRequest build(EmailType type, EmailRenderer emailRenderer) {              
          return new EmailRequest (to, type, emailRenderer);
      }
  }
  public class AdvertisementBuilder {
      private String topic;
      private EmailRequestBuilder emailRequestBuilder;
      // package private, so that only EmailRequestBuilder will be able to create it 
      AdvertisementBuilder(String topic, EmailRequestBuilder emailRequestBuilder) // mandatory parameters in constructor + reference to already gathered data {
          this.topic = topic;
          this.emailRequestBuilder = emailRequestBuilder;
      }

      // for optional parameters provide an explicit method that can be called 
      // but its not a mandatory call
      public AdvertisementBuilder withTargetAudience(String audience) {
          this.audience = audience;
          return this;
      }

      public EmailRequest buildRequest() {
          EmailRenderer renderer = new AdvertisementRenderer(topic, audience);   
          return emailRequestBuilder.build(EmailType.ADVERTISEMENT, renderer);
      }            
  }

  // A similar builder for DailyReport (I'll omit it but assume that there is a class
  class DailyReportBuilder {}

现在最好的部分是，作为用户，您现在不会出错。与这种结构的典型交互是:

  EmailRequest request =  EmailRequestBuilder.newEmailRequest("john.smith@gmail.com")
                     .ofAdvertisementType("sample topic") // its a mandatory param, you have to supply, can't go wrong
                     .withTargetAudience("target audience") // non-mandatory call
                     .buildRequest();

一些注释:

• 一旦您通过调用 ofDailyReportType/ofAdvertisementType 选择类型，用户就无法真正提供不同电子邮件类型的参数，因为它会“路由”到不具备电子邮件类型的构建器错误参数的方法。这样做的直接含义是自动完成功能将在您的 IDE 中运行，并且使用此方法的人将会感谢您;)

• 通过这种方式可以轻松添加新的电子邮件类型，不会更改现有代码。

• 也许采用这种方法，枚举 EmailType 将是多余的。我已将其保留在我的解决方案中，但如果不需要，您可能会删除它。

• 由于我有时会限制可见性(打包私有(private)构建方法、构造函数等)，因此创建请求将是 __the_only__ 方式，这意味着没有人会仅创建“内部”对象，因为可以这样做。至少恶意程序员在破坏封装之前会三思而后行:)