CODEWITHSUNDEEP
javaguavaimmutability
Robottinosino
Robottinosino

Reputation: 10882

How to design an immutable value class holding java.lang.String?

Objective

Create a class to be used as an immutable list of String objects.

Approach

I have decided to leverage Google Guava's ImmutableList<E> collection rather than wrapping a simple List<E> with Collections.unmodifiableList(List<? extends T> list) because I understand this avoids unnecessary concurrency checks on the backing List<E>, which is unaware of being wrapped (source: ImmutableCollectionsExplained).

Requirements

Nice-to-haves

Attempts

Here some attempts at it, although more combinations are possible. Forgive the humourous rendition.

Attempt #1 (including usage example)

import java.util.List;
import com.google.common.collect.ImmutableList;
class BritnetSpearsSpellings implements Iterable<String> {
  public static BritnetSpearsSpellings of(String... spellings) {
    BritnetSpearsSpellings britneySpears = new BritnetSpearsSpellings();
    britneySpears.spellings = ImmutableList.copyOf(spellings);
    return britneySpears;
  }
  private List<String> spellings;
  private BritnetSpearsSpellings() {
  }
  public List<String> getSpellings() {
    return spellings;
  }
}
@Override
public Iterator<String> iterator() {
  return spellings.iterator();
}
public class Usage {
  public static void main(String[] args) {
    for (String sepllin : BritnetSpearsSpellings.of("Brittany Spears", "Brittney Spears", "Britany Spears"))
      System.out.printf("You spel Britni like so: %s%n", sepllin);
    }
  }
}

Attempt #2

class BritnetSpearsSpellings implements Iterable<String> {
  public static BritnetSpearsSpellings of(String... spellings) {
    BritnetSpearsSpellings britneySpears = new BritnetSpearsSpellings();
    britneySpears.spellings = ImmutableList.copyOf(spellings);
    return britneySpears;
  }
  private ImmutableList<String> spellings;
  private BritnetSpearsSpellings() {
  }
  public ImmutableList<String> getSpellings() {
    return spellings;
  }
  @Override
  public Iterator<String> iterator() {
    return spellings.iterator();
  }
}

Attempt #3

class BritnetSpearsSpellings implements Iterable<String> {
  public static BritnetSpearsSpellings of(String... spellings) {
    BritnetSpearsSpellings britneySpears = new BritnetSpearsSpellings(ImmutableList.copyOf(spellings));
    return britneySpears;
  }
  private final ImmutableList<String> spellings;
  private BritnetSpearsSpellings(ImmutableList<String> spellings) {
    this.spellings = spellings;
  }
  public ImmutableList<String> getSpellings() {
    return spellings;
  }
  @Override
  public Iterator<String> iterator() {
    return spellings.iterator();
  }
}

Summary of differences

Question

Please help me choose among one of these implementations, with your reasoning behind the choice.

I think the main drawback of approach #2 is that clients need to have cognizance/visibility of the specialised Google Guava type and probably they shouldn't?

Upvotes: 8

Views: 860

Answers (3)

Daniel Pryden
Daniel Pryden

Reputation: 60947

From your problem statement ("there should be only one class for a given set of strings"), it sounds like what you really want is an Interner<ImmutableSet<String>>.

  • Interner is a utility (construct one with Interners.newStrongInterner()) for ensuring that you only have one instance of an object with any given data.
  • ImmutableSet is the right choice if your collection is immutable and a collection in arbitrary order that supports membership testing.

Alternately, you may want to look at a Cache<ImmutableSet<String>> (see Caches Explained for details).

Upvotes: 1

Frank Pavageau
Frank Pavageau

Reputation: 11705

Clearly, #3 is the best choice in my opinion. final enforces and documents the immutability of (that field of) the class, not only the fact that the List itself is immutable.

Whether you expose a List with some javadoc or an actual ImmutableList in the getter is another thing. I've seen opinions that returning an ImmutableList documents clearly the intention, but still, you're then tying yourself to an implementation instead of an interface for something that's low level and could need to change in the future (even if immutability is "generally" good). So it's more a global design choice for your application than for just one use case. If you do use ImmutableList, I don't think that's a real problem for the clients, the name is explicit and it can easily be seen through your IDE that it's an implementation of List, and they can access the javadoc if they want more information. And who knows, they might like it and start using it also, with all the other goodies Guava provides :-)

Upvotes: 3

Fabian Barney
Fabian Barney

Reputation: 14549

I would use Attempt #2 over Attempt #1, because it documents that you always return ImmutableList instances. In general it is useful to choose return types as specific as possible and parameter types as general as possible. But for both cases prefer Interfaces over concrete classes.

Well, ImmutableList is an abstract class and not an interface. But due to its nature it is acting very much like an interface.

Attempt #3 makes sense when your class member reference spellings cannot change for the object's lifetime and/or you want to get the whole class itself immutable. Otherwise when spellings can be assigned to another ImmutableList during the objects lifetime then it does not make sense.

Given the use case in your example I tend to say #3 is the best choice.

Upvotes: 0

Related Questions