Why getter & setter if return value is mutable?

Question

In C++ a getter & setter for a private data member is very useful due to the ability to control mutability via a const return value.

In Java, if I understand correctly (please correct me if I am mistaken), specifying final on a getter doesn't work that way. Once the caller received the data member reference through the getter, it can modify it, despite it being private...

If that's the case (and please correct me if I have a gross misconception here), why not declare the data member public and simplify things?

It is important to clarify that final does not mean constant. final means that the variable cannot be reassigned, but it says nothing about the object that it points to. — Jonathan Weatherhead, Sep 12 '11 at 14:44

score 25 · Accepted Answer · edited Oct 18 '14 at 15:32

Making immutable return values in java is a matter of either returning already immutable objects types (such as String) or returning a copy for non-immutable objects.

Sample 1 - Already immutable object

public String getValue() {
    return value;
}

Sample 2 - Collection of already immutable objects

public List<String> getValues() {
    return new ArrayList<String>(values);
}

Sample 3 - Non-immutable object

public Complex getComplex() {
    return complex.clone();
}

Sample 4 - Collection of non-immutable objects

public List<Complex> getComplex() {
    List<Complex> copy = new ArrayList<Complex>(complexs.size());
    for (Complex c : complexs) 
        copy.add(c.clone());
    return copy;
}

Sample 3 and 4 are for conveniance based on that the complex type implements the Cloneable interface.

Furthermore, to avoid subclasses overriding your immutable methods you can declare them final. As a side note, the builder pattern is typically useful for constructing immutable objects.

@Tomasz, true for this case. Let me edit to exemplify using not already immutable objects. — Johan Sjöberg, Sep 12 '11 at 13:52

Tomasz Nurkiewicz · Answer 2 · 2011-09-12T13:50:18.153

If you want your class to be immutable (i.e. having only final fields and getters) you must be sure that the values you return are immutable as well. You get this for free when returning Strings and built-in primitives, however some extra steps are necessary for other data types:

wrap collections with immutable decorators or defensively copy them before returning from a getter
make a copy of Date and Calendar
Only return immutable objects or defensively clone them. This also applies to objects in collections.

Note that if you defensively copy a collection, the client can view or modify the copy, but this does not affect the original collection:

return new ArrayList<Foo>(foos);

On the other hand if you wrap the original collection, the client is able to see all the changes that were introduced to the collection after the wrapper was created, but trying to change the contents of the wrapper will result in runtime exception:

return Collections.unmodifiableList(foos);

The bottom line is: Foo has to be immutable as well, otherwise the collection is immutable, but the client code can still modify members of the collection. So the same rules apply to Foo.

If that's the case (and please correct me if I have a gross misconception here), why not declare the data member public and simplify things?

Because:

you might wish to store mutable data inside an object and only provide immutable (read-only) view of the data (like wrapping collections)
you can change the implementation in the future, get rid of the field and for instance compute the value on the fly.

Yes, thank you. For a moment I thought that there is an `immutable` modifier on a method's return value that I missed. :) — ateiob, Sep 12 '11 at 13:54

score 3 · Answer 3 · answered Sep 12 '11 at 13:55

If you want to return an immutable view of a mutable standard container (eg list), then you should take a look at the Collections library:

http://download.oracle.com/javase/1.4.2/docs/api/java/util/Collections.html

It provides some useful wrappers such as unmodifiableMap and unmodifiableList. That way you don't have to make a wasteful copy. Of course, if the elements of the list are mutable, then this won't help as much -- there's no easy way in Java to get "deep" immutability. Of course, the same is true in C++ -- e.g., if you have a const vector of pointers to Foo objects, then the Foo objects themselves can still be modified (because const doesn't propagate across pointers).

score 0 · Answer 4 · answered Sep 12 '11 at 13:47

If that's the case (and please correct me if I have a gross misconception here), why not declare the data member public and simplify things?

First of all, the JavaBeans spec. requires you to provide getters (and setters for mutable properties).

Second, getters might enable you to add some logic, e.g. one getter might actually decide what to return (e.g. if the property is null return something differenc). If you didn't have getters in the first place you'd have more trouble to add such logic later on. With getters you'd just change the method without touching the callers.

Andy Thomas · Answer 5 · 2011-09-12T14:31:31.297

why not declare the data member public and simplify things?

Because information hiding makes it easier to manage and maintain a complex codebase. If the data members are private, you can change representation and behavior in one class, rather than throughout a large codebase.

Once the caller received the data member reference through the getter, it can modify it, despite it being private...

To clarify, a caller cannot modify a data member returned from a getter. It might be able to modify an object to which the data member points.

If this is a problem, and you're providing access through a getter, you can return an immutable instance, or a defensive copy.

The setter is also valuable for controlling modification to a referenced object. You can make a defensive copy in the setter.

Why getter & setter if return value is mutable?

5 Answers5