Should collection based properties be read only?

"urn:schemas-microsoft-com:office:office" />An
interesting question came up today on the issue of making all collection based properties
read only. In the usability studies we’ve done up to now, we’ve primarily focused
on collection based properties where the class exposing the property can truly claim
responsibility for populating the collection (e.g., the Files collection of a Folder
object). In such scenarios it makes sense to communicate to the user that the class
that exposes the property is (and must be) responsible for populating the collection.
This was shown to be reasonably intuitive in the studies we’ve done.

Making a collection read
only communicates additional semantics about the API that can help users understand
how the API works. In the Files collection, by making the Files property read only
we are communicating to some extent that we don’t want to allow the user to delete
all the files in a directory by assigning a new Files collection. In other words,
the user needs to be much more explicit about taking such potentially catastrophic
actions. This is one of the advantages of making the collection read only in this
case. Of course, making the property read only also protects the user from doing this
by mistake.

However, if responsibility
for populating the collection lies solely on the user, then making the property read/write
might communicate to the user that they are responsible for populating the collection
and that the class exposing the property can do nothing to help (as well as making
things more convenient for the user). If the responsibility for populating the collection
is shared between the class and the user, then I might consider exposing helper methods
that allow the developer to replace the collection, without setting it directly. But
I would not consider doing either of these for collection properties in which the
class exposing the property assumes responsibility for populating the collection.

It's unclear to me though
what the general expectations are for collection based properties. Do you always expect
these to be read only, or does it depend on the scenario or class exposing the property?
It would be great to hear your comments.

Comments

• Anonymous
  December 08, 2003
  In my development with .NET during the last two or three years I have found that Collection properties I expose from my classes are always owned by their exposing class. Even if the caller who gets the collection may modify its contents (an uncommon scenario even then) I do not allow for the actual replacement of the collection, and as such I have never exposed a set method for one. Any time such an assignment is allowed/required it is usually much more fundamental to the setup of the object exposing the collection and that assignment is then handled through a constructor overload or a public method that makes the assignment obvious.Further, to provide hints as to the expected usage I always take care to type the property with the most appropriate collection interface for its intended usage, e.g. returning IEnumerable for the most basic usages, ICollection when item counts might be required, only returning IList when the collection is expected/allowed to be modified by the caller, etc.
• Anonymous
  December 08, 2003
  Same sentiment here (ie. read-only use only).
• Anonymous
  December 09, 2003
  Usually read-only is best. But there are some situations, where a collection is extremely lightweight and designed to be replaced, where you want read-write. For example, the collection itself might be immutable, in which case read-write is the only way to change it. Or the collection may not be "owned" -- that is the real factor, probably: ownership. A collection of bools, a bit set, might be light and not "owned". In most cases you want ownership so the internal collection memory can be reused, and the user cannot break things.