枚举工厂式方法

发布于 2024-08-19 14:36:34 字数 513 浏览 1 评论 0原文

在我的应用程序中，可以生成几种不同的报告（CSV、HTML 等）。

我计划向枚举常量主体中添加一个方法，以创建并返回适当的报表对象，而不是创建传统的工厂式方法模式。

public enum ReportType {
 CSV {
  @Override
  public Report create() {
   return new CSVReport();
  }
 },
 HTML {
  @Override
  public Report create() {
   return new HTMLReport();
  }
 };

 public abstract Report create();
}

使用指定的 ReportType 枚举常量，我可以通过执行如下语句轻松创建新报告：

ReportType.CSV.create()

我想了解其他人对使用此方法的意见。您对此有何看法？您是否更喜欢其他方法？如果是，为什么？

谢谢

原文

In my application, several different reports can be generated (CSV, HTML, etc).

Instead of creating a traditional factory-style method pattern, I was planning on adding a method to the body of enum constants that would create and return the appropriate report object.

public enum ReportType {
 CSV {
  @Override
  public Report create() {
   return new CSVReport();
  }
 },
 HTML {
  @Override
  public Report create() {
   return new HTMLReport();
  }
 };

 public abstract Report create();
}

With a specified ReportType enum constant, I could then easily create a new report by executing a statement like the following:

ReportType.CSV.create()

I wanted to get the opinion of others on using this approach. What do you think of this? Would you prefer any other approach, and if so, why?

Thanks

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

栖竹 2024-08-26 14:36:34

我认为这两种方法都可以，但如果您不想知道正在生成哪种报告，那么我认为枚举方法是最好的。就像这样：

public class Person { 
    private String name;
    private ReportType myPreferedReportType;

    public ReportType getMyPreferedReportType(){
        return this.myPreferedReportType;
    }
    //other getters & setters...
}

假设您将一个 Person 实例保留在数据库上并稍后检索它 - 如果您使用多态性，那么您将不需要任何开关。你唯一需要做的就是
调用 create() 方法。例如：

Person person = null; 
//... retrieve the person instance from database and generate a 
//report with his/her prefered report type...
Report report = person.getReportType.create();

因此，如果您依赖多态性，则无需明确要求工厂为您提供 CVS/HTML/PDF，而是将这项工作留给 Enum 本身。当然，在某些情况下您可能需要使用其中一种，尽管我倾向于定期使用枚举方法。

I think both approaches are ok, but if you don't want to know which kind of report you're generating then I believe that the enum approach is the best. Like so:

public class Person { 
    private String name;
    private ReportType myPreferedReportType;

    public ReportType getMyPreferedReportType(){
        return this.myPreferedReportType;
    }
    //other getters & setters...
}

supose you persist a Person instance on a database and retrieve it later on - if you use polimorphism you won't need any switch wathsoever. The only thing you'll need to do is
to call the create() method. Like:

Person person = null; 
//... retrieve the person instance from database and generate a 
//report with his/her prefered report type...
Report report = person.getReportType.create();

So if you rely on polimorphism you won't need to ask a factory to get you the CVS/HTML/PDF explicitly, leaving that work to the Enum itself. But of course, there are situations that you may need to use one or another, although I tend to use the enum approach regularly.

回复收藏 0 原文

等待圉鍢 2024-08-26 14:36:34

使用枚举（例如创建报告）可以获得什么优势？如果您有工厂方法，您将创建一个 CSVReport 实例（例如），如下所示：
<代码> <代码>

Report csvReport = ReportFactory.createCSVReport();

>
我认为这比枚举更好地表达了意图。据我了解，枚举代表一组固定的常量，将其用作实例创建的工厂（尽管有效）在我看来似乎滥用了枚举的意图。

What is the advantage you gain by using enum for instance of Report creation ? If you had factory-method you would have created an instance of CSVReport (say) like below:

Report csvReport = ReportFactory.createCSVReport();

which I think conveys the intent better than the enum. As I understand Enumerations represent a fixed set of constants, and using it as a factory for instance creation (though works) seems to me misuse of the intent of Enumeration.

回复收藏 0 原文