Nov 30, 2016
Quite often, new Object Oriented programmers get confused as whether to inherit from a Class or from an Interface.
First of all, let me just explain that an Interface is a Class except that it is a fully abstract Class. An abstract Class is one which has at least one un-implemented method. So, if you create a class having several methods for all of which you have written code except for at least one of them, then you have to mark that class abstract. This class cannot be instantiated, it can only be inherited by a class. The inheriting class should then override that method and write its own code for it.
An Interface therefore, being a fully abstract class, means that all of its methods are left to the inheriting class to implement.
What you need to know in all of this is that the main reason we leave a method un-implemented is because we just want to impose a common feature to all the inheriting classes but don’t want to impose common behaviour. It will then be up to the inheriting class to individualise that feature. This way all different objects created from our class will have a common feature but exhibit them differently. For example all the classes that inherit from Shapes interface, have to implement their own Area and Perimeter calculations. So they will all be categorized as Shapes which means that they should be having Areas and Perimeters but a Triangle calculates its Area differently from a Rectangle. You can now create Objects that are of the same Type but have their own individual behaviours.
Having that in mind, there are two ways you can achieve this Generalization vs. Specialisation in Java.
Sometimes the category that we try to fit objects to, is so broad that almost none of the objects in it behave the same. Such as Shapes or Animals. There are millions of different animals out there, each behaving differently in their eating, reproducing, etc. but they all eat and reproduce etc. and that’s why they are called Animals. Therefore it makes sense to impose common features of animals and leave it to the individual animal to tell us how it does it. In other words the definition of Animal or Shape is too abstract to be able to carve in a code for it because there are many variations. In this scenario we define an Interface and get each Animal or Shape to implement it.
On the other hand assume we are going a bit more down the ladder and want to create objects of type Bird. Here we will find more of common specialisations such as the fact that all birds lay eggs. Therefore we can hard code laying eggs into a method and leave other special behaviours up to individual Bird species to code. This is an example of defining an abstract class to be Extended by its sub-classes, because only some of the behaviours are hard coded and enforced.
As we go further down the ladder in the classification of animals, we find that we can carve in even more concrete behaviour in classes because we are more confident about the common behaviour of that particular species and can leave less un-implemented methods to be overridden, and therefore less abstraction, to a point where all the common behaviour is known and hard coded in the definition of that species. We now have a concrete Class.
At this point we can create our own new species by extending that class and therefore inheriting its full behaviour and adding extra features to it.
In a nut shell, if you have situation where the objects you are creating belong to a Type whose all of its behaviour is dependent on individual objects then you need to define an Interface and implement it.
On the other hand if some of the behaviour of a type are known to be common to all its objects then create an abstract class and extend it by the sub-classes.
When all the behaviours are known to be common to all objects then create a concrete class. In this situation you can extend the class to create sub-classes of the same Type that behave the same but can also have their own features and behaviours.
Hope this has helped! For more information, take a look at our Java Training Courses.