Why use IList or List?

Question

I know there has been a lot of posts on this but it still confuses me why should you pass in an interface like IList and return an interface like IList back instead of the c

Answer 1

IEnumerable allows you to iterate through a collection. ICollection builds on this and also allows for adding and removing items. IList also allows for accessing and modifying them at a specific index. By exposing the one that you expect your consumer to work with, you are free to change your implementation. List happens to implement all three of those interfaces.

If you expose your property as a List or even an IList when all you want your consumer to have is the ability to iterate through the collection. Then they could come to depend on the fact that they can modify the list. Then later if you decide to convert the actual data store from a List to a Dictionary and expose the dictionary keys as the actual value for the property (I have had to do exactly this before). Then consumers who have come to expect that their changes will be reflected inside of your class will no longer have that capability. That's a big problem! If you expose the List as an IEnumerable you can comfortably predict that your collection is not being modified externally. That is one of the powers of exposing List as any of the above interfaces.

This level of abstraction goes the other direction when it belongs to method parameters. When you pass your list to a method that accepts IEnumerable you can be sure that your list is not going to be modified. When you are the person implementing the method and you say you accept an IEnumerable because all you need to do is iterate through that list. Then the person calling the method is free to call it with any data type that is enumerable. This allows your code to be used in unexpected, but perfectly valid ways.

From this it follows that your method implementation can represent its local variables however you wish. The implementation details are not exposed. Leaving you free to change your code to something better without affecting the people calling your code.

You cannot predict the future. Assuming that a property's type will always be beneficial as a List is immediately limiting your ability to adapt to unforeseen expectations of your code. Yes, you may never change that data type from a List but you can be sure that if you have to. Your code is ready for it.