When building an API, you should always think about who is going to use it. When the API is simply and clear to use, then the users are happy. When the users are happy then everyone is happy too. But great usability is not always easy to achieve. There are patterns that help on this, on this post I will focus on the classic builder pattern and how you can enhance it with the step builder pattern in order to build objects with a no brain interface, easy to use, impossible to get wrong. So lets start painting some context, we have 2 domain objects representing a user configuration to connect to some remote or local server. When remote credentials are required, when local no.
package com.marco.sbp;
public class UserConfiguration {
private final String name;
private ServerDetails serverDetails;
public UserConfiguration(String name) {
this.name = name;
}
public void setServerDetails(ServerDetails serverDetails) {
this.serverDetails = serverDetails;
}
public String getName() {
return name;
}
public ServerDetails getServerDetails() {
return serverDetails;
}
}package com.marco.sbp;
public class ServerDetails {
private final String host;
private String user;
private String password;
public ServerDetails(String host) {
this.host = host;
}
public void setUser(String user) {
this.user = user;
}
public void setPassword(String password) {
this.password = password;
}
public String getHost() {
return host;
}
public String getUser() {
return user;
}
public String getPassword() {
return password;
}
}We want to abstract the construction of the objects above using 2 different techniques, the classic builder pattern and the step builder pattern.
The classic builder pattern is pretty straightforward, it works masking the creation of the UserConfiguration and the ServerDetails using properly named methods like onLocalHost, onRemoteHost, etc.
package com.marco.sbp.builder;
import com.marco.sbp.ServerDetails;
import com.marco.sbp.UserConfiguration;
public class ClassicBuilder {
private String name;
private String host;
private String user;
private String password;
public ClassicBuilder(String name){
this.name = name;
}
public ClassicBuilder onLocalHost(){
this.host = "localhost";
return this;
}
public ClassicBuilder onRemoteHost(String remoteHost){
this.host = remoteHost;
return this;
}
public ClassicBuilder credentials(String user, String password){
this.user = user;
this.password = password;
return this;
}
public UserConfiguration build(){
UserConfiguration userConfiguration = new UserConfiguration(name);
ServerDetails serverDetails = new ServerDetails(host);
serverDetails.setUser(user);
serverDetails.setPassword(password);
userConfiguration.setServerDetails(serverDetails);
return userConfiguration;
}
}The step builder pattern is still using smart names to construct the object, but it’s exposing these methods only when needed using interfaces and proper encapsulation.
package com.marco.sbp.builder;
import com.marco.sbp.ServerDetails;
import com.marco.sbp.UserConfiguration;
/** "Step Builder" */
public class StepBuilder {
public static NameStep newBuilder() {
return new Steps();
}
private StepBuilder() {
}
public static interface NameStep {
/**
* @param name
* unique identifier for this User Configuration
* @return ServerStep
*/
ServerStep name(String name);
}
public static interface ServerStep {
/**
* The hostname of the server where the User Configuration file is stored will be set to "localhost".
*
* @return BuildStep
*/
public BuildStep onLocalhost();
/**
* The hostname of the server where the User Configuration file is stored.
*
* @return CredentialsStep
*/
public CredentialsStep onRemotehost(String host);
}
public static interface CredentialsStep {
/**
* Username required to connect to remote machine Password required to connect to remote machine
*
* @return BuildStep
*/
public BuildStep credentials(String user, String password);
}
public static interface BuildStep {
/**
* @return an instance of a UserConfiguration based on the parameters passed during the creation.
*/
public UserConfiguration build();
}
private static class Steps implements NameStep, ServerStep, CredentialsStep, BuildStep {
private String name;
private String host;
private String user;
private String password;
public BuildStep onLocalhost() {
this.host = "localhost";
return this;
}
public ServerStep name(String name) {
this.name = name;
return null;
}
public CredentialsStep onRemotehost(String host) {
this.host = host;
return this;
}
public BuildStep credentials(String user, String password) {
this.user = user;
this.password = password;
return this;
}
public UserConfiguration build() {
UserConfiguration userConfiguration = new UserConfiguration(name);
ServerDetails serverDetails = new ServerDetails(host);
serverDetails.setUser(user);
serverDetails.setPassword(password);
userConfiguration.setServerDetails(serverDetails);
return userConfiguration;
}
}
}Lets see now what is the user experience with both of our builders. The classic builder will be constructed using the name of the user configuration, then it will expose all of its methods leaving the user a bit too free to choose what’s next.
For example, a not careful user could end up with a UserConfiguration set with localhost where no authentication is required, still passing user and password.
This is confusing and it can lead to run-time exceptions.
These are some of the possible combinations of UserConfigurations that the user can end up with some are correct, lots are wrong:
A complete different story is with the step builder, here only the one step at the time is exposed:
If the credentials are not needed they will not be exposed and the build() method is offered only when the state of the object is sure to be coherent and complete:
Only 2 possible UserConfigurations can be built with this pattern, and both make sense and are clear to the user.
Conclusion
The step builder pattern is not the replacement of the classic Bloch one, sometimes you want to force the user to fill some parameter before advancing with the creation, in this case the step builder is doing the job, otherwise when a more open approach is required than the classic builder is your guy.
While this is a powerful approach it seems like this example might be overloading a class with multiple independent implementations. Wouldn’t it be better to have a local host and a remote host impl each with their own builder? I think the more interesting bit is not that you can specify multiple build orders but that you can direct the build order at all and distinguish between required and optional fields. A more interesting example might require a few fields and then return a classic builder for optionals.
Ex: Obj.builder().req1(x).req2(y).req3(z).opt5(a).opt1(b).build()