Builder

From APIDesign

Current revision

Builder pattern is an alternative to cumulative factory pattern. While the cumulative factory relies fully on immutability, the initial phase of a Builder empowers mutability. It is then followed by final call to a factory method to convert the temporarily mutable object into immutable one. It is very useful, especially in cases where the intermediate states created by the use of cumulative factory are incomplete and cannot be used by itself, or when mutability offers some obvious benefits. For example avoiding additional temporary actions (write to disk, establish connnection, etc.). Then the additional step of finishing the API calls by final use of factory method makes a lot of sense.

Imagine that we have an API representing a server...

Code from ServerConnector.java:

public final class ServerConnector {
    public String getName() {
        return name == null ? "noname" : name.getName();
    }
 
    public URL getURL() {
        return url == null ? null : url.getURL();
    }
 
    public void reset() {
        if (reset != null) {
            reset.reset();
        }
    }
 
    /** Additional method for API clients not available from first version.
     * @since 2.0
     */
    public void shutdown() {
        if (shutdown != null) {
            shutdown.shutdown();
        }
    }
}
 

...and we need a way to establish connection to it. For that purpose we can define additional class that has no getters, no way to obtain its state by external API clients. Instead it offers users of its API only setters allowing the clients to change enough properties before final creation of the connector is done:

Code from ServerInfo.java:

public class ServerInfo {
 
    public static ServerInfo empty() {
        return new ServerInfo(null, null, null, null);
    }
 
    public final ServerInfo nameProvider(NameProvider np) {
        this.name = np;
        return this;
    }
 
    public final ServerInfo urlProvider(URLProvider up) {
        this.url = up;
        return this;
    }
    public final ServerInfo reset(ResetHandler h) {
        this.reset = h;
        return this;
    }
 
    /** All one needs to do when there is a need to add new
     * style of creation is to add new method for a builder.
     * @param handler
     * @return
     * @since 2.0
     */
    public final ServerInfo shutdown(ShutdownHandler handler) {
        this.shutdown = handler;
        return this;
    }
 
    /** Creates the server connector based on current values in the 
     * info. Builder factory method.
     * @return server connector
     */
    public final ServerConnector connect() {
        return new ServerConnector(name, url, reset, shutdown);
    }
}
 

Usually the above methods destructively update the state of the builder object and return it back, so the calls can be chained. Alternatively one can use the cumulative factory and always return new instance of the intermittent build object (more declarative approach).

The interesting thing is on the Builder pattern is simplification of the internals of the ServerInfo class, as the class is know to never connect directly to any server. The class is just a recipe for creation of the connection:

Code from BuilderFactoryTest.java:

ServerInfo empty = ServerInfo.empty();
ServerInfo name = empty.nameProvider(prov);
ServerInfo urlAndName = name.urlProvider(prov);
ServerInfo all = urlAndName.reset(prov);
connection = all.connect();
 

The previous code snippet shows the verbose way to use the API. The shorter one-liner is also possible:

Code from BuilderFactoryTest.java:

connection = ServerInfo.empty()
        .nameProvider(np).urlProvider(up).reset(res).connect();
 

Builder pattern evolution characteristics are similar to the ones of the cumulative factory pattern. Yet the clear separation between configuration and functional part of the API may, in some situations, simplify internal implementation and prevent misuses (calling a setter after making the connection) of the class.

<comments/>