Why continue to use getters with immutable objects?

Question

Using immutable objects has become more and more common, even when the program at hand is never meant to be ran in parallel. And yet we still use getters, which require 3 li

Answer 1

It's a OOP practice to encapsulate fields and then expose it only through getters method. If you expose field directly this means that you will have to make it public. Making fields public is not good idea as it exposes inner state of object.

So making your field/data members public is not a good practice and it violates Encapsulation principle of OOP. Also i would say it's not specific to Immutable objects; this is true for non-immutable objects as well.

Edit As pointed by @Thilo ; Another reason : Maybe you don't need to expose how a field is stored.

thanks @Thilo.

Answer 2

Immutable objects should use direct field access for uniformity and because it allows one to design objects that perform exactly how the client expects they should.

Consider a system where every mutable field was hidden behind accessors while every immutable field was not. Now consider the following code snippet:

class Node {
    private final List<Node> children;

    Node(List<Node> children) {
        this.children = new LinkedList<>(children);
    }

    public List<Node> getChildren() {
        return /* Something here */;
    }
}

Without knowing the exact implementation of Node, as you must do when you design by contract, anywhere you see root.getChildren(), you can only assume one of three things is occurring:

• Nothing. The field children is returned as is, and you can't modify the list because you will break the immutability of Node. In order to modify the List you must copy it, an O(n) operation.
• It is copied, for example: return new LinkedList<>(children);. This is an O(n) operation. You can modify this list.
• An unmodifiable version is returned, for example: return new UnmodifiableList<>(children);. This is an O(1) operation. Again, in order to do modify this List you must copy it, an O(n) operation.

In all cases, modifying the returned list requires an O(n) operation to copy it, while read only access takes anywhere from O(1) or O(n). The important thing to note here is that by following design by contract you cannot know which implementation the library writer chose and thus must assume the worst case, O(n). Hence, O(n) access and O(n) to create your own modifiable copy.

Now consider the following:

class Node {
    public final UnmodifiableList<Node> children;

    Node(List<Node> children) {
        this.children = new UnmodifiableList<>(children);
    }
}

Now, everywhere you see root.children, there is exactly one possibility, namely it is an UnmodifiableList and thus you can assume O(1) access and O(n) for creating a locally mutable copy.

Clearly, one can draw conclusions about the performance characteristics of accessing the field in the latter case, whereas the only conclusion that can be made in the former is that the performance, in the worst case, and thus the case we must assume, is far worse than the direct field access. As a reminder, that means the programmer must take into account a O(n) complexity function on every access.

---

In summary, with this type of system, wherever one sees a getter the client automatically knows that either the getter corresponds to a mutable field, or the getter performs some sort of operation, whether it be a time consuming O(n) defensive copy operation, lazy initialization, conversion, or otherwise. Whenever the client sees a direct field access, they immediately know the performance characteristics of accessing that field.

By following this style, more information can be inferred by the programmer as to the contract provided by the object he/she is interacting with. This style also promotes uniform immutability because as soon as you change the above snippet's UnmodifiableList to the interface List, the direct field access allows the object to be mutated, thus forcing your object heirarchy to be carefully designed to be immutable from top to bottom.

The good news is, not only do you gain all the benefits of immutability, you are also able to infer the performance characteristics of accessing a field no matter where it is, without looking at the implementation and with confidence that it will never change.