Question

遇到设计问题，也许你可以帮忙决定。

我的客户端对象可以询问类Report的一组对象。有一组已定义的可用报告，根据客户的权限，不同的报告可以包含在返回的集合中。每个请求都会创建报告（每个客户端在每个请求上都会获得全新的报告实例）。

我是否应该使用一种“工厂”来封装报告创建，如下所示：

public class ReportsFactory {

    private UserPermissionsChecker permissionsChecker;

    public Set<Report> createReports() {
        Set<Report> reports = new HashSet<Report>();
        if(permissionsChecker.hasAccessTo('report A')) {
            reports.add(createReportA());
        }
        if(permissionsChecker.hasAccessTo('report B')) {
            reports.add(createReportB());
        }
        if(permissionsChecker.hasAccessTo('report C')) {
            reports.add(createReportC());
        }
        return reports;
    }

    private Report createReportA() {...}
    private Report createReportB() {...}
    private Report createReportC() {...}
}

这是所谓的简单工厂模式的正确用法吗？或者您有其他建议吗？

**编辑**

下面的一些评论说它不完全是工厂模式。如果没有，我怎么称呼它？

Answer 1

我认为设计是正确的，但这是“工厂”一词的错误用法。在工厂模式中，XxxxFactory创建Xxxx的实例，在需要时初始化它们，但不应用其他类型的逻辑。

这个设计在我看来是正确的，但是你的班级宁愿被称为ReportsService

也许UserPermissionsChecker可能是AuthorizationService

编辑：考虑对“服务”一词的批评。

目前在Java世界中存在一种相当普遍（我没有说普遍的）惯例，其中包括：

一个纯粹描述性的业务模型，由所有被称为（可能是错误的）POJO逻辑的类清空实现
所有业务逻辑主要与在名为XxxService的类的方法中以过程样式实现的对象Xxx相关。

我个人不同意这种编码风格，我更喜欢 object oriented programming ，但我们是否喜欢，这个约定存在于Java EE世界中并且具有连贯性。

判断OP提交的类的编码风格，我推断他遵循这种程序方法。在这种情况下，最好遵循现有约定并调用作为处理Reports ReportService的过程代码的容器的类。

Answer 2

对我来说，这看起来有点builder模式，从某种意义上说，你有一个对象，你可以构建它的数据。
这与工厂形成对比，工厂通常返回不同具体类型的创建对象，
通常，这些对象的数据构造是在具体类的CTOR中完成的，它们的对象是从工厂返回的。

这是工厂模式的正确用法吗？

2 个答案: