Is collection object better being immutable?

Question

As per this link, it is an advice that:

A good object should never change his encapsulated state. Remember, an object is a representative of a real-life entity, and this entity should stay the same through the entire life of the object. In other words, an object should never betray those whom he represents. He should never change owners. :)

Be aware that immutability doesn't mean that all methods always return the same values. Instead, a good immutable object is very dynamic. However, he never changes his internal state.

Is it better to re-introduce collections(in java) like class LinkedList maintaining immutability of state by supporting operations like add/remove item?

Without performance overheads, Can this collection(class LinkedList) be introduced as immutable collection?

Because, below are the advantages in favor of immutability:

• immutable objects are always thread-safe
• they help to avoid temporal coupling
• their usage is side-effect free

Answer 1

As per this link

Seeing as rule #1 is horrible, I would caution against taking the rest of the blog post as law. Though really, no blog post should be taken as law.

And the quote itself is rather contradictory:

• A good object should never change his encapsulated state.
• Be aware that immutability doesn't mean that all methods always return the same values.

Here's the thing, if you have immutable state, and your methods return different values then at least one of two things are true:

1. Your function varies based on its inputs.
2. Your function has side effects (works with something that does have mutable state).

(The example in the article hits on #2.)

The second of these conditions defeats the purpose of having immutable objects, and making that distinction between "encapsulated state" and other state is facetious at worst, impractical at best.

And the first of these conditions is good. Functions should only vary on their inputs where possible. Hiding the immutable state in the class harms that a little bit on the clarity front, but varies greatly on what you're actually doing.

Anyways, on to your question:

Without performance overheads, can such implementations(class LinkedList) be introduced by instantiating as immutable objects?

It depends on your language/implementation. Linked lists lend themselves fairly well to immutable construction because the innards of each "link" aren't really mutable. It's relatively easy to make new links with new pointers.

In Java, I doubt you could do such things without some overhead due to the hit to the garbage collector. You can't even do object pooling since there's no way to reuse the immutable objects reliably. And you certainly couldn't do it while maintaining the existing Java interfaces, which are designed with mutability (and maintaining a reference to the list) in mind.

Does a good object never change its state?

Such an absolute is not correct. Yes, immutability provides a number of benefits. Yes, you should probably default to making your objects immutable in Java and many other languages. But there are many perfectly good objects that change their state, and not a few objects (collections especially) where the mutable object is far better (more usable, more robust, more performant, more flexible, more maintainable) than an immutable design.

Answer 2

tl;dr The author seems to think all objects are value objects, but this is not true.

Value objects should be immutable because their existence represents a specific value out of some value space.

For example, an object that represents a pixel color value could be made immutable. The property of immutability can be used to reason about the problem more easily, reuse objects, cache computations, and more.

On the other hand, a thread object will need to reflect the status of a thread of execution, allowing you to query the state of the thread (myThread.isRunning(), for example). You can't expect this to work if the object were immutable, unless you can have the reference myThread swapped out from under you, but IMO this adds complexity that goes against the grain of the problem.

Answer 3

I think it's easier to reason about an object that doesn't change state once initialized. For example value objects are pretty easy to reason about. Assign a value and query for properties.

This is not always possible and I don't think it's a big deal, but it adds a level of complexity. Your methods might rely on a consistent internal state which is easier to break if your object keeps changing.

If you need go for an object that frequently changes state, the methods that change the state should be limited and documented. Limit your use of setters and prefer methods that "takes care of an action".

If complexity arise some further extraction might be needed, your Factory or something else, but I would not generalize the rule, I would judge case by case if the overhead actually solves a real problem.

I wouldn't worry about performance until I have a performance problem.

First Rule of Program Optimization: Don’t do it - Michael A. Jackson

Answer 4

Without performance overheads, can such implementations(class LinkedList<E>) be introduced by instantiating as immutable objects?

Yes, it can. In fact, a linked list is the prime example of a persistent immutable collection. (I assume by "without performance overheads" you are talking about persistence?)

public class LinkedList<E>
    extends AbstractSequentialList<E>
    implements List<E>, Deque<E>, Cloneable, java.io.Serializable {

    private final E value;
    private final LinkedList<E> next;

    static final empty = new Empty();

    LinkedList(E value, LinkedList<E> next) {
        this.value = value;
        this.next = next;
    }

    Optional<E> value() {
        return Optional.of(value);
    }

    Optional<LinkedList<E>> next() {
        return Optional.of(next);
    }

    private class Empty extends LinkedList<Object> {
        private Empty() {}

        Optional<E> value() {
            return Optional.empty();
        }

        Optional<LinkedList<E>> next() {
            return Optional.empty();
        }
    }
}

I don't know Java very well, but something like this should get you started.