[02/03/05] Interface vs. Abstract Class

I understand most of the differences between an interface and an abstract class. My question here is at what point is it more appropriate to use an interface instead of an abstract class.

The reason I'm asking this is because I've spent about 3 months writing this pretty complex open-ended (i.e. it uses plugins and will have an sdk) project that uses a large number of interfaces.

Looking back on it, I'm thinking that in many cases, it would be nice to implement defualt functionality for several members of several of the interfaces.

Is there increased language compatibility if I use interfaces? Or should I switch to abstract classes?

How would you tackle this problem?

There is a fairly substantial conceptual difference between inheriting a class and implementing an interface. A base class is something that a class is, whereas an interface is a role that a class can perform.

In the real world, Animal would be considered an abstract class. You can't just have an Animal instance wandering around. Every animal is some other more specialised type, like a Cat, a Dog or whatever, but they are all animals. A cat IS an animal; a dog IS an animal.

Something like Transport, on the other hand, would be considered an interface. In order to be considered Transport an object must have certain attributes, but there are many and varied modes of transport available: car, bus, horse, plane, skateboard, etc. All those things are Transport because they can do what Transport does, but I don't think anyone would consider them to all derive from a Transport class.

Your programming types should be essentially the same. If your type describes something that every subtype IS then it should be implemented as a class. If it describes what every, possibly very varied, subtype can do then it should be implemented as an interface.

In addition to jmcilhinney's response, I have read that base classes are preferred over interfaces in some situations. For instance, if you originally implemented something using an interface but later on had to add a method to the interface, all classes implementing that interface will have to change to include that method. If you're using a base class you can simply provide a default implementation.

Also, if you want an interface because conceptually it fits, but want to provide out-of-the-box functionality for some methods, consider using an interface along with a base class that implements the interface. You're users can have a choice of using the interface or a base class with built-in functionality.

An example of what DNA mentions is the IDbDataAdapter interface and DbDataAdapter class.

OK... so based on this... a graphics editor that implements layers as plugins could be set up as such:

All plugins implement the IPlugin interface. The application object provided to all plugins would be derived from the abstract ApplicationBase class or somesuch and the layers could either be derived from LayerBase (typical) or ILayer (advanced), both of which implement IPlugin?

I think I understand.

Thanks