I think that if you do a search you will see tons of documents explaining the difference. But I will resume it as this:
Interfaces can't have a default implementation for any method. Abstract classes can.
A class can implement any interface, but if you already have a class with a base type, it will not be capable of inheriting from an abstract class.
When to use each one?
In general I use both.
I create an interface so all methods can be reimplemented in many different ways (that helps in remoting, for example, or to create fake implementations for testing purposes).
But if some method is probably going to be implemented in the same way by many classes, I create an abstract class that already implement such method but let other methods be fully virtual.
A sample? If you look at the sample of my latest article
Creating your own animation format[
^] you will see the following:
IFrameReader. This interface has a non-generic untyped version that can be used if you have the right objects but don't know the generic type at compile time (that is, you pass parameters as objects).
Then it has a generic version that you can use and avoid casts if you know the right types at compile time (the ManagedBitmap<Rgb24> for example).
But, to those who want to implement a FrameReader class and don't want to lose time implementing both interfaces (as the untyped version will simple redirect to the typed version), there is the FrameReader class that already implements both interfaces. The untyped (non-generic) version simple redirects to the typed version, which keep those typed methods as abstract.
So, inheriting from the FrameReader class you get an already implemented IFrameReader but you still need to implement the methods that make the IFrameReader<T> work.
I hope this is clear enough.
Submit an article or tip