Builder patterns in the JTK

[chrisengelsma]

This is more of a talking point than an issue, but I'm curious what the curators of the JTK feel about implementing builder patterns to some of the objects within the JTK? There are some classes that have quite a lot of constructors, and implementing builder classes might be a good way to mitigate some of that. It would be quite a large paradigm shift, but might make extending the JTK easier to manage.

So for example, PlotPanel has 5 constructors:

PlotPanel()
PlotPanel(Orientation)
PlotPanel(int,int)
PlotPanel(int,int,Orientation)
PlotPanel(int,int,Orientation,AxesPlacement)

This could be reduced down to a single constructor:

PlotPanel(PlotPanelBuilder builder) {
    this.irow = builder.irow;
    this.icol = builder.icol;
    this.orientation = builder.orientation;
    this.axesPlacement = builder.axesPlacement;
}

And the builder will do all the heavy lifting as an public static class internal to PlotPanel:

public static class PlotPanelBuilder {
    private int irow;
    private int icol;
    private Orientation orientation;
    private AxesPlacement axesPlacement;

    public PlotPanelBuilder() {}

    public PlotPanelBuilder irow(int irow) {
        this.irow = irow;
    }

    /* etc....  */

    public PlotPanel build() {
        return new PlotPanel(this);
    }
}

In this scenario, one would then chain together any parameters they want into the builder and then output a PlotPanel. No need to add new constructors, you just modify the builder.

PlotPanel panel = new PlotPanel.PlotPanelBuilder()
    .irow(irow)
    .icol(icol)
    .orientation(orientation)
    .axesPlacement(axesPlacement)
    .build();

Anyways, it's one example. The logistics of an overhaul like this is huge, and would surely have to go through a deprecation to sunset the other constructors but I'm just curious what your thoughts are.