[concurrency-interest] Good terminology for setting up effectively immutable objects?
jed at atlassian.com
Mon Apr 28 20:48:27 EDT 2008
I thoroughly agree. Working on a large code-base with init methods
throughout, there is a lot to like about the guarantees that true
immutability gives you. Firstly you ensure that your objects are
correctly set up and all invariants are honoured. Secondly, you get
memory visibility guarantees regarding the initial values that you need
safe publication otherwise to achieve (well, true immutability gives you
safe publication without extra effort). Publication errors are some of
the most painful to diagnose and reproduce. You can also then make sure
that any builders are stack local.
As to making builder more palatable, whenever I have pointed out all the
problems with effective immutability and safe publication and the
potential gotchas of getting it wrong, the builder overhead starts to
look very attractive.
Mark Thornton wrote:
> Matthias Ernst wrote:
>> often I neither want a huge (number of) constructor(s) nor want to
>> jump through hoops of using a Builder to guarantee final-ness of my
>> object's dependencies but want to rely on effective immutability
>> instead. I want to rely on my clients' common sense that anything that
>> is not documented as changeable should not be changed during use. I.e.
>> a number of setters that they may only call a) before starting to use
>> the object and b) before publishing it to other threads.
> While I have written this sort of code often enough, I can't avoid the
> feeling that I should have used the builder pattern in most of the
> cases. In fact all of them, should probably have been genuinely
> immutable and not merely effectively immutable. Can we find a way to
> make the builder pattern more palatable?
> Mark Thornton
More information about the Concurrency-interest