List or IList [closed]

Answer 1

Interface is a promise (or a contract).

As it is always with the promises - smaller the better.

Answer 2

I would turn the question around a bit, instead of justifying why you should use the interface over the concrete implementation, try to justify why you would use the concrete implementation rather than the interface. If you can't justify it, use the interface.

Answer 3

You would because defining an IList or an ICollection would open up for other implementations of your interfaces.

You might want to have an IOrderRepository that defines a collection of orders in either a IList or ICollection. You could then have different kinds of implementations to provide a list of orders as long as they conform to "rules" defined by your IList or ICollection.

Answer 4

public void Foo(IList<Bar> list)
{
     // Do Something with the list here.
}

In this case you could pass in any class which implements the IList<Bar> interface. If you used List<Bar> instead, only a List<Bar> instance could be passed in.

The IList<Bar> way is more loosely coupled than the List<Bar> way.

Answer 5

Supprising that none of these List vs IList questions (or answers) mentions the signature difference. (Which is why I searched for this question on SO!)

So here's the methods contained by List that are not found in IList, at least as of .NET 4.5 (circa 2015)

• AddRange
• AsReadOnly
• BinarySearch
• Capacity
• ConvertAll
• Exists
• Find
• FindAll
• FindIndex
• FindLast
• FindLastIndex
• ForEach
• GetRange
• InsertRange
• LastIndexOf
• RemoveAll
• RemoveRange
• Reverse
• Sort
• ToArray
• TrimExcess
• TrueForAll

Answer 6

A principle of TDD and OOP generally is programming to an interface not an implementation.

In this specific case since you're essentially talking about a language construct, not a custom one it generally won't matter, but say for example that you found List didn't support something you needed. If you had used IList in the rest of the app you could extend List with your own custom class and still be able to pass that around without refactoring.

The cost to do this is minimal, why not save yourself the headache later? It's what the interface principle is all about.