Question

Abstract classes are described as being useful for a family of objects (e.g. could be used for animals which are mammals). However, what difference is there between using an interface or abstract class for representing a family of related objects?

My process is to use an abstract class when I want to define common functionality but with the option for future extensions and an interface for custom functionality (implementations).

For example, I wrote an abstract class to encapsulate some database functionality which will be used heavily in a small web app at work. I wrote an abstract class with virtual methods which can be overrided with custom functionality in the future (e.g. logging, or some reporting of the database events which may be required).

Is this the right way to go? Is there any significance in choosing one construct (abstract or interface) to represent a family?

Answer 1

An abstract class should be used when there is common state and behavior between all types. An interface should be used when all types will have a common interface but will not share state or behavior.

Here is an example.

German Shepherd, Golden Retriever, Beagle

These three objects are all dogs, and as such they share certain common state (carnivorous, 4 legs, etc.) and they also share certain overridable behavior (bark, pant, etc.). In this instance it would make the most sense to create an abstract Dog class to hold this common state and behavior and create subtypes of Dog for each type of dog.

Pencil, Pen, Chalk

These objects have no common state and they cannot share behavior. Yet you may notice that they do have something in common – they are cabaple of writing. These objects are best build separately and without a base class and then tied together with a Writable interface that exposes each type’s Write method.