attaboy182
attaboy182

Reputation: 2079

private final vs public final fields in immutable objects (java)

Item 15 in Effective Java states that it's recommended to use private final fields as against public final fields in an immutable object as it might prevent changing the internal representation in a later release.

I'm having trouble understanding the highlighted part - I can't see a case where changing an access specifier could cause an issue when it's already final. Could someone please provide an example for this?

Upvotes: 2

Views: 974

Answers (2)

Garbage
Garbage

Reputation: 1520

I am not sure about "later release" part, but keeping variables private become important specially in case of (possibly) mutable properties like List. Though you can't reassign the reference to a new List, you can always add or remove elements from the list if it's public.

Upvotes: 0

Jon Skeet
Jon Skeet

Reputation: 1499860

It's not a matter of just changing access specifier - you might change everything about the internal representation.

Suppose you have three byte values as part of the state of your object. You could store them in a single int field, or you could store them in three byte fields. If you keep the field (or fields) private, providing access to the state only, you can change your implementation later. If you use public fields, your storage detail becomes part of the API of your class, and can't be changed without breaking compatibility.

How your class stores state should be an implementation detail, hidden from the outside world for future flexibility.

(This isn't just a theoretical concern. As an example, in my Noda Time project in .NET, my v2.0 release will radically change the storage details for dates and times. If I'd made the state available as fields, that would be a large breaking change. As I've used properties instead, this change is completely transparent to users other than in terms of improved performance.)

Upvotes: 9

Related Questions