Possible Duplicate:
What is the difference between List (of T) and Collection(of T)?
I have a static class and a getter to return my List Collection. Now I read and have been told to return ICollection rather than List. What is the advantage of using public static ICollection over public static List?
static class Storage
{
private static List<string> store;
static Storage()
{
store = new List<string>();
}
public static ICollection<string> getList
{
get
{
return store.AsReadOnly();
}
}
public static void addString(string add)
{
store.Add(add);
}
public static void removeString(string remove)
{
store.Remove(remove);
}
public static void display()
{
foreach (String view in store)
{
Console.WriteLine(view);
}
}
}
}
IEnumerable<T> provides access to a forward only cursor over a series of T objectsICollection<T> provides the same as IEnumerable<T> but also a Count property (meaning the collection has a definitive end)IList<T> provides the same as ICollection<T> but also random access to any element within the list via an indexer (list[5])
List<T> implements all of the above.
The benefit of using a simpler interface as an argument or return value is that it gives more flexibility to the caller and can help to document how the object will be used (or is intended to be used in the case of a return value).
It's good practice and more maintainable. If you use an interface instead of a type then your code is not hard coded to that type (List).
Example: Say you later decide to change your Storage class to persist your data in another type of storage (i.e., database, XML, etc.) You might use Entity Framework to connect to a database, or your might use LINQ-to-objects.
Actually, you might want to consider using IEnumerable or IEnumerable<string>. These types work very will with LINQ as well as most any other type of collection. Thus you could transition to LINQ without changing the return type and reworking all of the code that deals with your Storage class.
And, perhaps string isn't the best choice either? What are you storing? Maybe you should create a class for the objects you are storing (i.e. Name). Then you would want to return an IEnumerable<Name>.
class Name
{
public string Name { get; set; }
}
Later you might want to add access to FirstName and LastName to your class:
class Name
{
public string Name
get
{
return string.Format("{0} {1}", FirstName, LastName);
}
public string FirstName { get; set; }
public string LastName { get; set; }
}
By using IEnumerable<Name> you don't have to change any of your consuming code to do this--as long as you support the original interface of your Name class you can add the extra features without breaking anything.
Now, if you migrate to a different return type, you should also consider migrating all of the code that deals with Storage to the new type as well. When you 'bake in' the storage type everywhere in your code as List you are making it more difficult to make future changes. You might not appreciate this right now, but as you become a better programmer or find yourself making future changes you will see the benefit of using an interface that permits changing the underlying type. Try to anticipate future possibilities when you select the types of objects and accommodate them in the first revision and you will save headache when you add things later.
If you are asking why return an interface over an object, the interface describes what the object does and how it is used rather than requiring a specific implementation. It makes the code more generic.
If you are asking why a Collection rather than a List, collections do not imply an order whereas a List does. The technical term is that Collections are "weaker" and so apply to more situations. If you do not need ordering, use a Collection. Otherwise, use a List.
