Custom Collection using IEnumerable vs ICollection vs IList

Question

I need to design my own custom GenericCollection class. Now i have plenty of options to derive it using IEnumerable, ICollection, and IList, where later offers some added functionalities.

I am little confused that if i go with IEnumerable<T> i might require declaring the object to actually hold the collection like in this case _list.

public class GenericCollection<T> : IEnumerable<T>
{
    private List<T> _list;
    //...
}

But if i go with ICollection<T> or IList<T>, i do not require to declare the List object as it is implicitly available.

public class GenericCollection<T> : IList<T>
{
    // no need for List object
    //private List<T> _list; 
    //...
}

What is the difference between these two approaches with respect to performance?

In which scenario each one is preferred especially when it comes to designing your own collection. I am interested in the light weight collection with good performance. I think this can be achieved using IEnumerable<T> but how exactly along with some strong reasons to go with it?

I have reviewed some existing posts but none is giving required information.

Returning 'IList' vs 'ICollection' vs 'Collection'

Answer 1

IEnumerable, ICollection, and IList (generally, any type with an I prefix) are just interfaces. They let you expose what your class will do, but unlike if you inherit a class, interfaces do not provide you a default implementation of any of the things they say you must do.

As far as choosing which interface, here's a quick guide:

• An IList is an ICollection that can be accessed by index.
• An ICollection is an IEnumerable with easy access to things like Add, Remove, and Count.
• An IEnumerable is anything that can be enumerated, even if the list of those things doesn't exist until you enumerate it.

Some classes that you might want to extend (or keep as a private field that runs most of the logic) for your collection are List<T>, Collection<T>, (which implements IList<T>, but with easier access to overriding implementation, see Collection<T> versus List<T> what should you use on your interfaces? for the big differences between these two) ObservableCollection<T>, or collections that are not lists, like Dictionary<T, U> and HashSet<T>. For more info on any of these, look up the MSDN documentation on the class.

Answer 2

The performance is unlikely to be dependent on which interfaces are implemented. It rather depends on how many instructions the processor has to run to achieve a certain goal. If you implement IEnumerable and wrap over the List, you are likely to end up writing Add/Remove/this[] methods that are just propagating the calls to the List, which would add a performance overhead. Hence, although I didn't take any measurements, the inheritance approach would likely be a very little bit faster.

However, such details usually matter only for real-time applications with an extreme need to save every possible CPU cycle. Eric Lippert has a great article about paying attention to such details: http://blogs.msdn.com/b/ericlippert/archive/2003/10/17/53237.aspx. Generally, you are likely to be better off using the approach that better fits business logic and architecture of your application, rather than performance details.

Answer 3

First off, you don't have to actually choose betwen these interfaces, if it's necessary you can implement all three. Second, implementing IEnumerable does not require you to make the underlying list public. You can implement just the methods to use the Enumerator of the underlying list.

Performancewise, I doubt there'll be much of an impact, focus on what you need functionally. The only way to know for sure is to measure.