So, I've looked at some similar questions asked here in regards to how these three should be used in naming. Usually, the answer is something along the lines of "it's conventional" and "just be consistent". I'm wondering if that's the same answer for my question.

I have an interface StatSet defined as

public interface StatSet {

    int getHitpoints();

    int getAttack();

    int getDefense();

I want to define an implementation, where all fields are defined in the constructor:

public final class ReadOnlyStatSet {

    public ReadOnlyStatSet(final int hitpoints, final int attack, final int defense) {
        this.hitpoints = hitpoints;
        this.attack = attack;
        this.defense = defense;

    public int getHitpoints() {
        return hitpoints;

    public int getAttack() {
        return attack;

    public int getDefense() {
        return defense;

    private final int hitpoints;
    private final int attack;
    private final int defense;
    // no other fields

My question is: is ReadOnlyStatSet the best name for this type of class. Or, would Immutable be more suited. In which grammar would I use one over the other.

  • That's as good a name as any. I agree with the prior advice: be consistent. Mar 23, 2015 at 23:50
  • I like the Cocoa standard of classes being implicitly immutable and you would denote the mutable versions, for example NSArray vs NSMutableArray.
    – Matthew
    Mar 24, 2015 at 4:00
  • 2
    "Immutable" is more specific than "read-only", as it implies the object can't be changed at all, not only by owner of a given reference (there is no writable reference elswhere).
    – Basilevs
    Mar 24, 2015 at 5:36

2 Answers 2


Any of the above seem logical. Immutable, Unmodifable and ReadOnly all are acceptable choices. It is important however, that you stick to a convention. If some of your classes are 'Immutable' while others are 'ReadOnly', this could imply that there is a difference, which could confuse a consumer of your public code.

I personally use and prefer Immutable to describe objects which cannot be mutated, but I also see no reason why anybody who follows a different approach is wrong.

On an aside, I have seen Google's Guava project use 'Immutable', such as in ImmutableSet, while the Java collections use 'Unmodifiable', such as UnmodifiableSet. The only difference I have been able to discern is that Guava's ImmutableSet and friends are their own instances of a collection, while UnmodifiableSet and friends are wrappers which provide an 'Unmodifiable' view of a collection which may change underneath. A consumer of the UnmodifiableSet view cannot change the collection, but someone with a reference to the wrapped collection underneath could change what the UnmodifiableSet contains, so one could very easily argue that the UnmodifiableSet is not 'immutable.' This might be why it was not named as ImmutableSet when it was created.

  • 1
    "Immutable" and "Read-only" is not the same. Immutable: "cannot be changed and won't be changed over time". Thus a getter will always return the same result. Read-only: "You can't change it" This does not mean that others can't. The values might change.
    – piegames
    Sep 27, 2017 at 15:43
  • Yes. See the last paragraph of my answer
    – Dogs
    Sep 28, 2017 at 13:20

Naming your object immutable/read-only/unmodifiable seems superfluous.

It seems strange to me that you need to use immutable, read-only, unmodifiable or whatever else in the class name if the class already acts as immutable.

That's something that you should describe using keywords/class structure but not by the name of the class.

  • The implication is that there are multiple implementations of StateSet, and this one in particular is immutable. Mar 24, 2015 at 2:00
  • Plenty of 'high-quality' examples disagree with you. For example, Guava's ImmutableSet, or Java's own UnmodifiableSet. The whole point of including immutable or unmodifiable or whichever other keyword you choose is to make it immediately clear (without having to read javadocs or source code) that the object is immutable, especially if the class is implementing an interface which has mutators that simply throw UnsupportedOperationException or something similar.
    – Dogs
    Mar 24, 2015 at 2:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.