job.answiz.com
  • 4
Votes
name

I love the immutable "pattern" because of its strengths, and in the past I have found it beneficial to design systems with immutable data types (some, most or even all). Often when I do so, I find myself writing fewer bugs and debugging is much easier.

However, my peers in general shy away from immutable. They are not inexperienced at all (far from it), yet they write data objects the classic way - private members with a getter and a setter for every member. Then usually their constructors take no arguments, or maybe just take some arguments for convenience. So often, creating an object looks like this:

Foo a = new Foo();
a.setProperty1("asdf");
a.setProperty2("bcde");

Maybe they do that everywhere. Maybe they don't even define a constructor that takes those two strings, no matter how important they are. And maybe they don't change the value of those strings later and never need to. Clearly if those things are true, the object would be better designed as immutable, right? (constructor takes the two properties, no setters at all).

How do you decide if an object type should be designed as immutable?Is there a good set of criteria to judge it by?

I currently am debating whether to switch a few data types in my own project to immutable, but I would have to justify it to my peers, and the data in the types might (VERY rarely) change - at which time you can of course change it the immutable way (create a new one, copying the properties from the old object except for the ones that you want to change). But I'm not sure if this is just my love for immutables showing through, or if there is an actual need for/benefit from them.

And maybe they don't change the value of those strings later and never need to. Clearly if those things are true, the object would be better designed as immutable, right?

Somewhat counter-intuitively, never needing to change the strings later on is a pretty good argument that it doesn't matter if the objects are immutable or not. The programmer is already treating them as effectively immutable whether the compiler enforces it or not.

Immutability doesn't usually hurt, but it doesn't always help either. The easy way to tell if your object might benefit from immutability is if you ever need to make a copy of the object or acquire a mutex before changing it. If it never changes, then immutability doesn't really buy you anything, and sometimes makes things more complicated.

You do have a good point about the risk of constructing an object in an invalid state, but that's really a separate issue from immutability. An object can be both mutable and always in a valid state after construction.

The exception to that rule is that since Java supports neither named parameters nor default parameters, it can sometimes get unwieldy to design a class that guarantees a valid object just using overloaded constructors. Not so much with the two-property case, but then there's something to be said for consistency as well, if that pattern is frequent with similar but larger classes in other parts of your code.

  • 0
Reply Report

There are two major ways to decide if an object is immutable.

a) Based on the nature of the Object

It is easy to catch these situations because we know that these objects will not change after it is constructed. For example if you are have a RequestHistory entity and by nature history entities do not change once it is constructed. These objects can be straight forward designed as immutable classes. Keep in mind that Request Object is mutuable as it can change its state and whom it is assigned to etc over the time but request history do not change. For example, there was a history element created last week when it moved from submitted to assigned state AND this history entitiy can never change. So this is a classic immutable case.

b) Based on the design choice, external factors

This is similar to java.lang.String example. Strings can actually change over the time but by design, they have made it as immutable due to caching/string pool/concurrency factors. Similary the caching/concurrency etc can play a good role in making an object immuatble if caching/concurrency and related performance is vital in the application. But this decision should be taken very carefully after anlyzing all the impacts.

The main advantage of immutable objects is they are not subjected to tumble-weed pattern.i.e the object will not pick up any change over the life time and it makes the coding and maintenance very very easier.

  • 0
Reply Report

Seems like you're approaching it backwards. One should default to immutable. Only make an object mutable if you absolutely have to/just can't make it work as an immutable object.

  • 3
Reply Report