1

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.

closed as primarily opinion-based by durron597, gnat, user40980, user22815, GlenH7 Aug 4 '15 at 18:22

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • That's as good a name as any. I agree with the prior advice: be consistent. – Robert Harvey Mar 23 '15 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 '15 at 4:00
  • 1
    "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 '15 at 5:36
3

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.

  • "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 '17 at 15:43
  • Yes. See the last paragraph of my answer – Dogs Sep 28 '17 at 13:20
-2

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. – raptortech97 Mar 24 '15 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 '15 at 2:02

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