Here is the best explanation I've read...

"...think at a much higher level. When you're designing an object model:

* interfaces describe "can do" relationships.
* abstract classes describe "is a" relationships.

Or, to put it another way

* interfaces share appearance but not implementation
* abstract classes share both appearance and implementation

When you're trying to decide whether to use an interface or an abstract class, ask yourself:

* is there any situation where two COMPLETELY different objects would need to be treated as the same?

* is there a fundamental "core" of implementation that needs to be shared by EVERY implementation?

* is there a sensible "is a" relationship? A Giraffe IS A Mammal IS AN animal.

* is there a sensible "can do" relationship? A Bitmap CAN DO disposal. "

Eric Lippert

from http://discuss.techinterview.org/default.asp?joel.3.89283.9

Our application allows for customization on a per-client basis. We define a class that implements an interface for the customization. The class is instanciated using a factory method. Because it implements an interface, we know what methods are available and can call them appropriately, however, the implementation is different for each customer. I tried to implement this with an abstract class but had trouble getting it to work. No problems with an interface.


>I know there was a thread a few weeks ago, but I can't find it.
>
>I have been reading about interfaces, and I understand the concept, but my question is "So What?" I just don't see them being helpful other than to enforce standards. Should all of my classes have an interface? What does that gain me?
>
>Also, when should I use an interface as opposed to inheritance? I am just not "getting" it and I figured it was about time to do something about it.