Is this right usage of factory pattern?

Question

Got design problem, maybe you can help to decide.

My client object can ask for set of objects of class Report . There is defined set of available reports and according to client's permissions different reports can included in returned set. Reports are created per request (every client gets brand new report instances on each request).

Should I use kind of "factory" that will encapsulate reports creation like below:

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() {...}
}

Is this right usage of so called simple Factory pattern? Or do you have other suggestions?

** EDIT **

Some comments below say it's not exactly Factory pattern. If not, how could I call that?

Answer 1

I think the design is correct, but this is a wrong usage of the "Factory" word. In the Factory pattern, XxxxFactory creates instances of Xxxx , initializes them if required, but applies no other kind of logic.

This design here seems correct to me, but your class would rather be called ReportsService

And maybe UserPermissionsChecker would be AuthorizationService

Edit: To take into account criticism against the word "Service".

There is currently a quite widespread (I did not say universal) convention in the java world, which consists in having:

• A purely descriptive business-model implemented by classes emptied of all logic called (maybe mistakenly) POJOs
• All business logic mainly related to an object Xxx implemented in a procedural style in the methods of a class called XxxService.

I personally don't agree with this coding style and I prefer object oriented programming , but whether we like it or not, this convention exists in the Java EE world and has it's coherence.

Judging bye the coding style of the class submitted by the OP, I inferred that he followed this procedural approach. In that situation, it's better to follow the existing convention and call the class that serves as a container for the procedural code which handles Reports a ReportService.

Answer 2

To me this looks a bit of a builder pattern, in a sense you have an object, that you build its data to.
This is in contrast to a factory, where usually returns different concrete types of created objects,
And usually the construction of the data of these objects is done in the CTORs of the concrete classes that objects of them are returned from the factory.