Which pattern best describes decoupling file building from output file format?

Question

A common feature we have is a report be available available in multiple formats. For example, a pricing report will be available as an Excel spreadsheet for the marketing team to be able to tweak the numbers, as a PDF report to look nice for external customers, and as ASCII text for emailing/SMS-ing out the sales staff.

We accomplish this by decoupling the creation of the output with the report using an interface like

public interface DocumentMaker{
    void makeSectionHeader( String s );
    void makeParagraph( String s );
    void makeFootnote( String s );
    ...
    String make();
}

et cetera. The report logic itself then calls these methods without knowing what the final format of the report it will be.

We end up referring to this pattern as the "builder pattern" (and often use that as our naming) but it does not feel like that is an appropriate application of the pattern. The builder pattern is described as:

Instead of using numerous constructors, the builder pattern uses another object, a builder, that receives each initialization parameter step by step and then returns the resulting constructed object at once.

However, we aren't really interested in the object returned, and often all variations return the same type (eg. String).

It actually, seems closer to the strategy pattern which is described as:

The strategy pattern defines a family of algorithms, encapsulates each algorithm, and makes the algorithms interchangeable within that family. Strategy lets the algorithm vary independently from clients that use it

Which sounds more like we are doing.

Although a colleague suggests that they are abstract factories:

The client doesn't know (or care) which concrete objects it gets from each of these internal factories, since it uses only the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from their general usage and relies on object composition, as object creation is implemented in methods exposed in the factory interface.

So, is what we are doing appropriate to call the "builder pattern"? If not, is there a more appropriate pattern to call it?

Answer 1

Your class is definitely a Builder. I would change some names to be more consistent with other implementations of this pattern.

public interface DocumentBuilder {
  void addSectionHeader(String s);
  void addParagraph(String s);
  void addFootnote(String s);
  ...
  String build();
}

Factories and strategies (typically) accomplish a task within single method invocation.