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'

Mook

you are not required to have _list member in the first example. In addition, you still have to implement some storage mechanisms in case of inhering from IList and implementing public interface with respect to IList – Cosme

Generic collection? sounds like a List to me... – Cone

You can change the underlying implementation, Generic Collection is just a wrapper. – Mook

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.

Waken

Answer 2

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.

Adventist

I mistakenly added public List, thanks for pointing though. What is the use of implementing all three interfaces? And if i will focus on the functionality alone then i can also go with List<T> with added and ready to serve functionalities. But i am looking for some strong reasons to go for IEnumerable<T>, if any? – Mook

Seeing as Ilist implements IEnumerable, you don't need implement it explicitly if you implement IList. I just meant to say it's not an either/or question. – Adventist

Answer 3

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.

Decor