The Builder design pattern enables us to construct...

# feed

[Dave Leeds]

The Builder design pattern enables us to construct complex objects in multiple steps. But how much of it is relevant for a modern programming language like Kotlin? In today's 10-minute video, we'll see a traditional implementation of the Builder Pattern, and then we'll see how we can improve upon it with Kotlin's language and library features.

https://www.youtube.com/watch?v=7lEDGpa7sGw▾

[Arjan van Wieringen]

I am missing the main reason of using a builder pattern. That is the fact that you want to avoid people being able to construct an object in an invalid state. Constructors are an implementation detail on how to construct the object and a wrong set of arguments can trigger an invalid state. The GoF explicitly state that the builder pattern is there to address this issue.

Creation of complex objects, for instance large configuration objects, can be made consistent and valid by even returning separate builder interfaces in the intermediate steps. Rust has excellent support in this in the so-called Type State Pattern

Your example, with the nullables, can be easily overcome by just using listOfNotNull and is imho not a reason to use the builder.

A builder isn’t there for esthetics

[Dave Leeds]

Hey Arjan. Maybe you've got a different edition of the GoF Design Patterns book than I've got, but in my copy, I can't find anything explicit about the prevention of invalid states being a motivation for a builder pattern. The main benefits include shielding the Director from internal representations of the Product, and allowing "finer control over the construction process" (p. 100). Even with just constructors, I'm not sure that we ever need to allow a wrong set of arguments that could put it into an invalid state.

[Arjan van Wieringen]

I’ll try to find my copy ;) but that was what I took out of it.

How would you disallow a wrong set of arguments in the constructor? With an exception?

[Arjan van Wieringen]

My bad, it was in Effective Java 😐

With the flexibility of Kotlin language I rarely need the builder though. But only when a class construction is so complex, which is a smell, do I resort to it and mainly for the invalid state reason.

[Dave Leeds]

Ah, thanks - that explains it! I haven't actually read that one. 🙂

For the constructor, it'd probably help to have a more specific example to discuss. But generally speaking, if we're talking about child objects that need corresponding values, then some combination of constructor overloads and types that relate the corresponding values. I try to use exceptions in constructors just for basic ("primitive") types that can't be typed more specifically (e.g., an Int that has to be within a certain range or a String that has to have a certain length).

Anyway, definitely agree that we don't often need a builder in Kotlin, especially since we have so many ways to insert expressions in constructors - whether with scope functions, list operation chains that remove nulls, etc.

Thanks again, Arjan!

[Arjan van Wieringen]

It's my pleasure. I like these discussions 🙂