Builder

From APIDesign

Builder pattern is composed from inital configuration cumulative factory pattern phase followed by final call to a factory method. 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. If an additional action (write to disk, establish connnection, etc.) is needed, it makes sense to finish the API calls by final use of factory method.

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

does not exists: aserverinfo.builder.api

...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 (or in this case cumulative factory methods) allowing the clients to change enough properties before final creation of the connector is done:

does not exists: aserverinfo.builder.factory

The API use is not complicated over the case of cumulative factory. Moreover the writer of the API can simplify internals of his 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:

does not exists: ServerConnector.builder.creation.verbose

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

does not exists: ServerConnector.builder.creation

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/>