Assume an interface that allows queries on a spatial tree

public ISpatialTree
    int FindChildIndex(Vector point);
    bool IsLeaf { get; }
    ICollection<ISpatialTree> Children { get; }

and another one that allows changing the tree:

public ISpatialTreeWriter : ISpatialTree
    void Add(Vector point);
    bool Remove(Vector point);
    void Clear();

I am looking for a name to denote the writeable interface. Ideally it would be reasonably short and readable word. It's not only for this example, but I would like to use a convention for all code in the project because this is a common case.

Does anyone know of a good convention for this problem? What conventions are used in other projects?

Words that were discussed include Writer (ambiguous, often used in other contexts), Mutator (confusing), Rw (unreadable, not a word).

A good solution would be a single word, not longer than 6-8 letters and that makes it obvious that this is the writer interface.

  • So you want a short suffix but -Rw will not do. What about -W or is this too long either? Or what exactly is the reason for not chosing -Rw? To be honest, I would question that whole thing. What's so bad about having a -Writer interface, which is a clear and intitively understandable meaning? You have code completion, you don't have to write it. And the compiler will surely not complain.
    – JensG
    May 14, 2014 at 9:17
  • Well, writer is ambiguous because this class doesn't write out to files. It doesn't have to be 2 characters or something, a word is fine, but it should be as clear and unambiguous as possible. Rw is bad because it is not a word, it doesn't read nicely.
    – Wilbert
    May 14, 2014 at 9:21
  • 1
  • 1
    IWritableSpatialTree, ISpatialTreeWriteAccess
    – JensG
    May 14, 2014 at 9:23
  • @gnat I rephrased to be not opinion based. How can I fix this question? I am sure there are projects that have such a convention; I just don't know them.
    – Wilbert
    May 14, 2014 at 9:30

2 Answers 2


Writer and Mutator are a bad choice because they imply mutating something else. If you change the object itself, the proper forms are Writable and Mutable.

If you have a readonly interface but the underlying object can be changed through another interface, that object isn't immutable. This implies that mutability vs. immutability is not the distinction you want to make here.

So only ReadOnly, ReadWrite or Writable remain. Since you don't have WriteOnly access at all you don't need to distinguish ReadWrite from WriteOnly. ReadWrite isn't a proper word, so I'd rather go with the simpler Writable.

Following the convention of the existing collections in .NET, the appropriate choices would be IReadOnlySpatialTree and ISpatialTree, where the latter is writable.

If most of your code is only reading and write access is the exception, you could deviate from this convention and use ISpacialTree as the readonly interface and IWritableSpacialTree as the writable interface.

  • 1
    +1. I think this follows the .NET convention of things like ICollection vs ReadOnlyCollection, the former of which is mutable, the later of which isn't.
    – KChaloux
    May 14, 2014 at 12:28
  • @KChaloux The latter is a wrapper and can still change its contents through the underlying collection. So it's only readonly, not immutable. May 14, 2014 at 12:40
  • +1 emphasizing the ReadOnly aspect makes more sense, indeed.
    – JensG
    May 14, 2014 at 20:04
  • I would suggest "Readable" is a much better term than "ReadOnly", and would suggest that the contract for an interface IReadOnlyFoo should specify that code with a reference to an implementing object should be able to pass that reference directly to outside code safely without that outside code being able to modify the underlying object. Although MS failed to make such a distinction, I would posit that ReadOnlyCollection<T> should implement both IReadableList<T> and IReadOnlyList<T>, while List<T> should implement only the former.
    – supercat
    May 8, 2015 at 17:50

I would suggest that you specify a read-only interface style, such as:

interface IReadOnlySpatialTree

and then the writeable interface extends this with its name only, ie.:

interface ISpatialTree : IReadOnlySpatialTree

You will rarely use a writeable interface without also needing the readonly part. If you're not careful you'll end up with at least 3 interfaces for every type (readonly/ writeonly and readwrite), which isn't particularly useful and is a waste of energy to maintain.

Having a readonly interface is useful, as these methods are presumably pure, which simplifies caching and other aspects. It also means one can ensure that writes do not happen unintentionally. However, for a writeable interface, being also to read also doesn't really matter- the readonly interface doesn't have side-effects.

There is the rather weird method List<T>.AsReadOnly in the .NET framework, as MS didn't consider readonly in the first place.

  • 1
    There was a mistake in my question; of course I only want two: the basic one (readonly) and the writer (read+write). The writer should implement the readonly one, of course, as you correctly noted.
    – Wilbert
    May 14, 2014 at 10:11
  • 1
    The O in ReadOnly should be uppercase to fit with the existing readonly collections in .NET. May 14, 2014 at 10:31

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