Post permalink

ReadOnlyCollection implements IList<T>'s members only explicitly, so they are inaccessible when the ROC is not cast as an IList<T>, and even then every mutator operation throws an exception.

ROC is meant to be a Decorator wrapper around another list (which can be modified). I think ROCs work best with C#'s auto-implemented properties:

class PublicFacingCollection : ReadOnlyCollection<Object> { // I often alias generic types like this for readability and semantics}

class Foo {

public PublicFacingCollection TheCollection { get; private set; }

private List<Object> underlyingCollection;

public Foo() {

underlyingCollection = new List<Object>();

TheCollection = new PublicFacingCollection(underlyingCollection); // the PublicFacingCollection instance no-longer needs to be dealt with by the Foo owner class. The underlyingCollection can be modified and the changes shown up in the TheCollection property
instantly. Consumers of the Foo type do not see any mutator methods of the ROC as they are implemented explicitly.

}

}

I am at least somewhat acquainted with ReadOnlyCollection. In any case, I consider ReadOnlyCollection vs. IEnumerable as mostly apples vs. oranges. Changing nothing else about your example, what would be the drawback to defining TheCollection as type IEnumerable<Object>?