Nov 23, 2012 09:23 AM|gerrylowry|LINK
Short answer: you may want to use an interface if you're going to need a form of multiple inheritance.
http://msdn.microsoft.com/en-us/library/6sh2ey19.aspx "List<T> Class"
List<T> uses several interfaces:
public class List<T> : IList<T>, ICollection<T>,
IList, ICollection, IReadOnlyList<T>, IReadOnlyCollection<T>, IEnumerable<T>,
Simply put, if you want to enforce a contract, then you may want an interface. However:
"Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries", Second Edition, Krzysztof Cwalina; Brad Abrams; Addison-Wesley Professional, October
22, 2008; Print ISBN-10: 0-321-54561-3, Print ISBN-13: 978-0-321-54561-9, Web ISBN-10: 0-321-54567-2, Web ISBN-13: 978-0-321-54567-1, Pages in Print Edition: 480
classes are the preferred construct for exposing
The main drawback of
interfaces is that they are much less flexible than
classes when it comes to allowing for evolution of APIs. After you ship an
interface, the set of its members is fixed forever. Any additions to the
interface would break existing types that implement the
A class offers much more flexibility. You can add members to
classes that have already shipped. As long as the method is not
abstract (i.e., as long as you provide a default implementation of the method), any existing derived
classes continue to function unchanged.
note: while the book is mainly applicable to designing API's, much of its information is also applicable generically.