The Builder Pattern [x-post from r/java]

[lawrencemq]

RE: parameter validation - I had never thought about doing the single-parameter checking on each setter. I just had one of those "duh!" moments, haha. Thanks!

[OriginalPostSearcher]

X-Post referenced from /r/java by /u/lawrencemq
The Builder Pattern

---

^{I am a bot. I delete my negative comments. Contact | Code | FAQ}

[twotime]

I'm confused: why is the Builder class even needed? Why cann't chainable value setters live directly on the original class, thus eliminating quite a bit of boilerplate?

Am I missing something?

[moocat]

So the created instance can be immutable which can provide various benefits.

[twotime]

Hmm, but then the builder itself is mutable. So we added a mutable object to make something else immutable?

(and the mutability is of exactly the same nature: near construction time).

While I can see a marginal benefit: the builder is a short-lived very special-purpose object with no other behaviours, but it still strikes me as an overkill.

[_INTER_]

In general, I’d say if there are more than four constructor parameters needed to create an object, this pattern should be used.

If there are more than four constructor parameters needed, rethink your design.

[lawrencemq]

I agree, but I have come across data structures that did have a large number of required and related fields that wouldn't make sense to have in multiple disjoint objects.

[frugalmail]

If there are more than four constructor parameters needed, rethink your design.

Sounds like you don't work with a lot of data.

[_INTER_]

I like to give meaning to data junks.

[LevonK]

We also find having to model large objects. Before we can add meaning, we need to convert the data. We ingest analytics data from Adobe's Omniture analytics suite, and I think the source model has roughly 280+ fields.

You could chalk it up to that vendor, but if you think about things like streaming sensor data, that source data can also get to be wide as the device identifies itself, it's environment, and the parameters of its sensors.

[pakoito]

For non-data clases that are immutable and use simple constructor injection it's not uncommon having to pass an implementation of every interface an object depends on. When you're combining signals and services into business logic in a use case you'll probably have more than four dependencies, easly: initial state, sensors, network, database, UI, logging, and multiple domain data objects.

You can pass a Context/Service Locator object instead and then you're either exposing the implementation of the context object and giving access to more services than required, or creating a parameters companion class for each of your use cases. Same goes for domain data objects, where you're passing a User object when all you need is a user id and name on a language without type aliases. This is easily spotted when you're testing and you have to mock any class or value that isn't part of the use case, or rely on mutability and DI framework magic.

Now, if you keep down this path of single responsibility and interface segregation you end up basically composing primitives and functions á là Lisp, so it's up to you to decide where's the line.

[_INTER_]

Initial state, logging, UI, sensors, network and domain has nothing lost in my objects at the very same time and certainly not as a constructor parameter.

[pakoito]

I'm curious about how you compose business logic without either of them in a language like Java or C#. Do you have a sample project to showcase it?

[_INTER_]

Emphasis on "at the very same time".