Builder - Creational Design Pattern


981 words • 6 min read
design-patterns
, , ,

While coding we often encounter cases when we may need a lot of arguments for a function. This can become tricky sometimes and can lead to confusion among the user of the function. Sometimes they me pass wrong order of arguments and sometimes they can miss a few. This becomes even harder when a few arguments are optional while others are mandatory. We can solve such problems using the Builder Design Pattern.

Let’s first explore a few cases without the use of a builder class.

Too Many Arguments

There are many built in classes in many programming languages that takes too many arguments. We can take example of a custom java class that we use for configuring the HttpREquests. 

1
2
3
4
5
6
7
8
9
10
HttpRequestConfig config = new HttpRequestConfig(
    5000,               // connectTimeout
    10000,              // readTimeout
    true,               // followRedirects
    false,              // useCaches
    "qurious-x/v1.0",   // userAgent
    "proxy.local",
    8080,               // port 
    true                // keepAlive
);

The same is true for a JavaScript function to configure the API requests which can look something like: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
function createHttpRequestConfig(
    url,
    method,
    timeout,
    async,
    cache,
    userAgent,
    onSuccess,
    onError,
    retries
) {
    return {
        url: url,
        method: method,
        timeout: timeout,
        async: async,
        cache: cache,
        userAgent: userAgent,
        onSuccess: onSuccess,
        onError: onError,
        retries: retries
    };
}

Using a Builder

We saw above that the functions which takes too many arguments can lead to confusions to the callers of the functions and sometimes it’s too much code causing readability issues and has a maintenance cost. The maintenance cost comes into picture when we try to make change to such function and backwards compatibility goes on toss!

The builder pattern is a design pattern that allows for the step-by-step creation of complex objects using the correct sequence of actions. The construction is controlled by a director object that only needs to know the type of object it is to create.

We can now refactor the above codes to use a Builder Class to ease the pain of developers and maintainers. Let’s look at the refactored code. 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
function HttpRequestConfigBuilder() {
    this.url = "";
    this.method = "GET";
    this.timeout = 5000;
    this.async = true;
    this.cache = false;
    this.userAgent = "DefaultAgent";
    this.onSuccess = function(){};
    this.onError = function(){};
    this.retries = 0;
}

HttpRequestConfigBuilder.prototype.setUrl = function(url) {
    this.url = url; 
    return this;
};

HttpRequestConfigBuilder.prototype.setMethod = function(method) {
    this.method = method; 
    return this;
};

HttpRequestConfigBuilder.prototype.setTimeout = function(timeout) {
    this.timeout = timeout; 
    return this;
};

HttpRequestConfigBuilder.prototype.setAsync = function(async) {
    this.async = async; 
    return this;
};

HttpRequestConfigBuilder.prototype.setCache = function(cache) {
    this.cache = cache; 
    return this;
};

HttpRequestConfigBuilder.prototype.setUserAgent = function(agent) {
    this.userAgent = agent; 
    return this;
};

HttpRequestConfigBuilder.prototype.onSuccess = function(fn) {
    this.onSuccess = fn; 
    return this;
};

HttpRequestConfigBuilder.prototype.onError = function(fn) {
    this.onError = fn; 
    return this;
};

HttpRequestConfigBuilder.prototype.setRetries = function(n) {
    this.retries = n; 
    return this;
};

HttpRequestConfigBuilder.prototype.build = function() {
    return {
        url: this.url,
        method: this.method,
        timeout: this.timeout,
        async: this.async,
        cache: this.cache,
        userAgent: this.userAgent,
        onSuccess: this.onSuccess,
        onError: this.onError,
        retries: this.retries
    };
};

And when the caller will use it, it will be called like this: 

1
2
3
4
5
6
7
8
9
10
var cfg = new HttpRequestConfigBuilder()
    .setUrl("/api/data")
    .setMethod("GET")
    .setTimeout(5000)
    .setCache(false)
    .setUserAgent("qurious-x/v1.0")
    .onSuccess(function(data) { console.log(data); })
    .onError(function(err) { console.error(err); })
    .setRetries(3)
    .build();

And the Java code when using a Builder will be refactored like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
public class HttpRequestConfig {
    private final int connectTimeout;
    private final int readTimeout;
    private final boolean followRedirects;
    private final boolean useCaches;
    private final String userAgent;
    private final String proxyHost;
    private final int proxyPort;
    private final boolean keepAlive;

    private HttpRequestConfig(Builder builder) {
        this.connectTimeout = builder.connectTimeout;
        this.readTimeout = builder.readTimeout;
        this.followRedirects = builder.followRedirects;
        this.useCaches = builder.useCaches;
        this.userAgent = builder.userAgent;
        this.proxyHost = builder.proxyHost;
        this.proxyPort = builder.proxyPort;
        this.keepAlive = builder.keepAlive;
    }

    public static class Builder {
        private int connectTimeout = 5000;
        private int readTimeout = 10000;
        private boolean followRedirects = true;
        private boolean useCaches = false;
        private String userAgent = "DefaultUserAgent";
        private String proxyHost = null;
        private int proxyPort = -1;
        private boolean keepAlive = true;

        public Builder connectTimeout(int v) { this.connectTimeout = v; return this; }
        public Builder readTimeout(int v) { this.readTimeout = v; return this; }
        public Builder followRedirects(boolean v) { this.followRedirects = v; return this; }
        public Builder useCaches(boolean v) { this.useCaches = v; return this; }
        public Builder userAgent(String v) { this.userAgent = v; return this; }
        public Builder proxy(String host, int port) { this.proxyHost = host; this.proxyPort = port; return this; }
        public Builder keepAlive(boolean v) { this.keepAlive = v; return this; }

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

// using the builder 

HttpRequestConfig config = new HttpRequestConfig.Builder()
    .connectTimeout(5000)
    .readTimeout(10000)
    .followRedirects(true)
    .userAgent("MyApp/1.0")
    .proxy("proxy.local", 8080)
    .keepAlive(true)
    .build();

Conclusion

The Builder Pattern is a helpful way to create objects that need many settings or optional details. Instead of forcing developers to remember long lists of arguments, the builder lets us set only what we need using simple, readable steps. This makes code easier to understand, safer to use, and more flexible as the project grows. It also helps avoid mistakes that happen when arguments are in the wrong order or when new features are added later.

Still, the Builder Pattern is not perfect. It adds more code, can hide which values are required, and may feel unnecessary for simple objects. If the builder and the main class get out of sync, it can also lead to bugs. Even with these drawbacks, the Builder Pattern remains popular because it solves a common problem in everyday programming: creating complex objects in a clean, clear, and reliable way.

References