Question

as far as I understand, getters/setters should always make copies, in order to protect the data.

However, for many of my classes, it is safe to have the getter return a reference to the property asked for, so that the following code

b = a.getB();
b.setC(someValue);

actually changes the state of object a. If I can prove that it is OK for my class, is it good practice to implement the getter this way? Should the user then be notified of this, for example in the Javadoc? I think that this would break the implementation-hiding paradigm, so, should I always assume that the state of a did not change, and make a call to the setter

b = a.getB();
b.setC(someValue);
a.setB(b);

Thanks in advance
S

Answer 1

There’s a good argument in your above example that since A is maintaining a reference to B, A should look after B, and not hand it out but manipulate it on your behalf. Otherwise you can argue that you’re breaking encapsulation (since A reveals it has a reference to B), and ideally objects should do things for you, rather than export their contents such that you can manipulate them.

Having said all that, the above is certainly not an uncommon practise and often a pragmatic choice.

When you expose an object via get(), you have three options:

1. expose the actual object
2. make a defensive copy
3. expose an object that wraps the original, but prohibits modification. e.g. you can wrap the original object in a restricted interface. See (for example) Collections.unmodifiableCollection() which wraps the original collection (and doesn’t copy it) but provides an interface that doesn’t permit modification.

Whatever you do, you should document it in the interface (and hence in the Javadoc). Otherwise you’re at liberty to change it later, and dependent code can easily break.