2

The builder pattern is one of the most popular creation patterns, and it has numerous benefits. I specifically want to understand if immutability of the model object itself is one of the key benefits. All the while I thought it was, but I could not find any backing documentation on the same. Consider this scenario, you are creating an object from a network call (from json let's say). We create model objects and it has a Builder inline. This is what everybody does. The members of the model are also private. Since this is a network object, the members won't have setters. My doubts are

  • With builder securing object creation, do we need to make members private.
  • Can we instead keep them public final and eliminate need for getter()
  • In general (irrespective of the above two points), shouldn't all non-settable members be final? I don't see many people making members final, why is it so? Is this a good approach or not?
Codevalley
  • 4,593
  • 7
  • 42
  • 56
  • Your questions appear to be, [Why use getters and setters?](https://stackoverflow.com/q/1568091/1371329) and [Mutable vs immutable objects](https://stackoverflow.com/q/214714/1371329). – jaco0646 Aug 13 '20 at 13:09

1 Answers1

0

I'm really having my pain with the example you chose. Parsing JSON into objects is really something you can delegate to JSON-B / Jackson / insert JSON library here nowadays. But I get it that we're on a theoretical level here.

Wikipedia just says: The intent of the Builder design pattern is to separate the construction of a complex object from its representation.

From the theory, the builder pattern neither forces immutability nor is it any aspect of it.

With builder securing object creation, do we need to make members private.

You don't need to do anything. But there is one simple stylistic rule: You either access members by getters and setters or by making them public. But not both.

Can we instead keep them public final and eliminate need for getter()

Final would imply immutability - if that's what you want to achieve, you can do so.

In general (irrespective of the above two points), shouldn't all non-settable members be final? I don't see many people making members final, why is it so? Is this a good approach or not?

You only make members final if you want them to be immutable or if they are constants. Otherwise it makes no sense. With your example, I can only think of constant values? However, you cannot make members final without setting their value. You either need to set them in the constructor or initialise them to null. But having final null values most likely doesn't serve any purpose.

The better approach for such values would be really just not to define a getter or setter and making it private. But then you again have just some useless null values laying in your class.

To be frank, this whole discussion about getters/setters or public is opening Pandora's box. I have had too many discussions about this by now, and it just doesn't matter which way you do it. In the end both serve the same purpose: setting and retrieving values.

Regarding final values: I don't have to use immutability often to be frank, in my area of development I can't really think of any case I've used it so far. The only thing I use it for is to mark constant values which I don't want to be changed by anything.

In the end, this whole discussion about design patterns is tedious. A builder is just a helping structure. You have to find your way on how to use it for your use case and in your company. Just remind you of the fact that it's whole purpose is to make the creation of complex objects more accessible.

maio290
  • 6,440
  • 1
  • 21
  • 38
  • JSON was a loose example. Point I was trying to make was that when the model holds information coming from an external source, (which should not be mutated and lost). And in those scenarios, immutability is obviously important. I was specifically talking in that cohort, how to use Builder in the right way. Also, on the point around members not being final, as a general good practice, I declare everything as final, and if required downgrade it. This is to avoid downstream mistakes which could unwantedly change the value of variables. – Codevalley Aug 13 '20 at 06:37
  • final != constant. I can keep a variable final and initialise it on constructor. I find it as a good practice to start everything immutable and make required things mutable, this makes the code less susceptible to unintended value replacements downstream. – Codevalley Nov 11 '20 at 12:42