Question

Often you have to implement a collection because it is not present among those of the .NET Framework. In the examples that I find online, often the new collection is built based on another collection (for example, List<T>): in this way it is possible to avoid the management of the resizing of the collection.

public class CustomCollection<T>
{
    private List<T> _baseArray;

    ...

    public CustomCollection(...)
    {
        this._baseArray = new List<T>(...);
    }
}

1. What are the disadvantages of following this approach? Only lower performance because of the method calls to the base collection? Or the compiler performs some optimization?
2. Moreover, in some cases the field relating to the base collection (for example the above _baseArray) is declared as readonly. Why?

Answer 1

1. The main disadvantage is the fact that if you want to play nice you’ll have to implement a lot of interfaces by hand (ICollection, IEnumerable, possibly IList… both generic and non-generic), and that’s quite a bit of code. Not complex code, since you’re just relaying the calls, but still code. The extra call to the inner list shouldn’t make too big of a difference in most cases.
2. It’s to enforce the fact that once the inner list is set, it cannot be changed into another list.

Usually it’s best to inherit from one of the many built-in collection classes to make your own collection, instead of doing it the hard way. Collection<T> is a good starting point, and nobody is stopping you from inheriting List<T> itself.