Differences between Abstract Classes and Interfaces

I’m sure this topic has been discussed many times before and will be discussed many times again. However, I think there is a very interesting and important meta-discussion going on that is being left out of the spotlights.

Of course, there is a very simple and effective answer to this question. You can implement (parts of) an abstract class, whereas you cannot implement an interface and in most languages you can only inherit from one (abstract) class where you can implement as many interfaces as you like.

This answer is both practical and useful, but it also clouds the ‘real’ discussion, which revolves around the following question: When you are defining an Abstract Class without any implemented methods, should you define an Interface instead? Why (not)?

This question cannot be answered by the practical argument. The argument from practicality is not concerned with definitions, but with practical use. This is not a bad thing, but it ís a choice. And that choice is: do definitions matter to you? Do you want to think about these things, do you see value in them? If not, no worries. But you and I are not participating in the same discussion, then.

Because I do see a lot of value in defining my terms as precisely as I can. This does not mean I want to stall every discussion with questions like ‘define what a definition is!’, but I do want to make sure we are all talking about the same thing. And an Abstract Class and an Interface are just not the same thing.

For the record: an Abstract Class is a node in the inheritance tree that has no business being instantiated, for example a mammal. An Interface is a sort of contract that is only a set of capabilities, such as flight. Extending an Abstract Class forms an ‘is a’ relationship, whereas implementing an Interface forms a ‘can do’ relationship. If you are interested in ‘implementing’ ‘capabilities’, you may want to look into Aspect Oriented Programming.