Question

The code looks like below:

namespace Test {     public interface IMyClass     {         List<IMyClass> GetList();     }      public class MyClass : IMyClass     {         public List<IMyClass> GetList()         {             return new List<IMyClass>();         }     } } 

When I Run Code Analysis i get the following recommendation.

Warning 3 CA1002 : Microsoft.Design : Change ‘List’ in ‘IMyClass.GetList()’ to use Collection, ReadOnlyCollection or KeyedCollection

How should I fix this and what is good practice here?

Answer 1

To answer the ‘why’ part of the question as to why not List<T>, The reasons are future-proofing and API simplicity.

Future-proofing

List<T> is not designed to be easily extensible by subclassing it; it is designed to be fast for internal implementations. You’ll notice the methods on it are not virtual and so cannot be overridden, and there are no hooks into its Add/Insert/Remove operations.

This means that if you need to alter the behavior of the collection in the future (e.g. to reject null objects that people try to add, or to perform additional work when this happens such as updating your class state) then you need to change the type of collection you return to one you can subclass, which will be a breaking interface change (of course changing the semantics of things like not allowing null may also be an interface change, but things like updating your internal class state would not be).

So by returning either a class that can be easily subclassed such as Collection<T> or an interface such as IList<T>, ICollection<T> or IEnumerable<T> you can change your internal implementation to be a different collection type to meet your needs, without breaking the code of consumers because it can still be returned as the type they are expecting.

API Simplicity

List<T> contains a lot of useful operations such as BinarySearch, Sort and so on. However if this is a collection you are exposing then it is likely that you control the semantics of the list, and not the consumers. So while your class internally may need these operations it is very unlikely that consumers of your class would want to (or even should) call them.

As such, by offering a simpler collection class or interface, you reduce the number of members that users of your API see, and make it easier for them to use.