Using Abstract Classes And Interfaces

Introduction

This article is going to be a short one with some details about the interfaces and abstract classes in java. There have been a lot of confusion about using them interchangeably, but as I always say, encapsulation is a strong feature of java and one of the most important rule in java is that every thing has its own purpose. Hence, if two distinct features (abstract class and interface) exists in the language, then they must have different reasons as well.

Purpose of the Article

The article describes in detail using Abstract Classes And Interfaces, what is the difference between interfaces and abstract classes in terms of design and how a good API should differentiate between both of them. What should be your consideration while writing an API. When to use interfaces and where to use abstract classes. Please read till the end if you are looking for an answer which can impress the interviewers 🙂

I would also like to talk about abstraction before writing about the differences here. Before starting I would like you to have a look at the picture below and think for a while and answer the question below:
collage
Question: If I ask you to categorize the objects in the picture there can be many categories. Few of them are listed below:
Vehicles

  1. Aeroplane
  2. Tank
  3. Bike
  4. Truck
  5. Bicycle
  6. Boat
  7. Car

Flyable

  1. Kite
  2. Bird
  3. Aeroplane

We can have many more categories but for this discussion we can be good with two.

What exactly did we notice or categorized? What is the basis of the categorization?.
I would say features, I may also say behaviors and I can also say capabilities. The first category is based on feature/behavior and the second category is more of a capability based behavior.

Now that we have some understanding of how to categorize things, its time to introduce the term ‘Abstraction’. We must understand this very clearly that a features, behaviors and capabilities are different.
Capability is what an object can do. Behavior is what an object does and feature is defined by the properties of an object.

There is a strong feeling and we see that the objects in the first category make more sense to be together, they seem to be inseparable or I may say closely related. Where as the objects in the second category are more of a group and they need not exist closely.

Abstraction

The word abstract by definition of dictionary means “Thought of or stated without reference to a specific instance”. This precisely means that we declare a behavioral aspect and features of an object kind which is yet not concrete.

Abstraction is a programming construct, which helps in abstracting the features/behavior of a given type or related type of objects to form an hierarchy or group. Let me try to define it in a simpler way:

Let us say we are trying to write an application which manages vehicles. Now let us list what kind of vehicles we can have, we can have trucks, cars, motor bikes, bicycles, aircraft, boats etc. Moreover, if we closely notice none of them are concrete instances, I will never say I have a truck or a car or a motor bike. I will prefer to say that I have a car Ca which is of make Honda, black in color with registration number ABC1234 etc. Basically something which can uniquely identify the car Ca.

So the car Ca is a concrete instance of Vehicle. Similarly we can have multiple concrete instances for each of the class of vehicles.

Where does abstraction fit in?

As we discussed above, I trust that abstraction must be used to impart a feature or a behavior, now we clearly notice that all the vehicle can have few features in common, like they will have an engine number, a color, max speed and many more.

Ways to use abstraction

Abstraction can be used with the help of the following language features:

Abstract classes

Assume I ask you to create an instance of a Car, there is a chance that few of these crucial features are missed if every individual is going to write an implementation. Also I would like to force the users of my API to provide these common features of all the vehicles.

This is to maintain a common set of features across all the vehicles, this is where abstraction or need of abstract class comes. We abstract the common features to another class, also it is a good practice to have a special class for this purpose which would not make a logical sense if we instantiate it. For e.g if we instantiate a Vehicle it might not make much sense. But if we instantiate a Car that makes more sense. So when we are writing the API we would like to use abstract classes for internal usage (within the API).

Interfaces

Interfaces mostly have to be used for the second part/categorization where a capability is to be imparted. So interfaces clearly can be implemented with objects which are not closely related.
There is a sense of loose coupling when we think of interfaces. I must say that if we are trying to provide an API to the users(external usage) we would prefer to provide interfaces.

The big debate

If Interface and Abstract classes both can impart a behavior to the classes which extend or implement them then why not always use an interface because it gives more room to the implementing class to extend another class.

The answer would be slightly lengthier. When we talk about imparting behavior both interfaces and abstract classes can equally do good, but when we talk about imparting properties to the children, or may be we can say features then abstract classes can do better because the class extending it can get all the protected member variables of a parent abstract class.

In fact this is not the answer to the question, the answer is that in a good design practice, one would always want to use abstract classes to define a set of closely related classes. This means if we want to write an API and define an hierarchy of objects which can be used with each other within the API, we must go for an abstract class.

To use an interface we need a better reason, if we are trying to provide an API to the users we would prefer to provide them an interface as they are just contracts which define that if some class is trying to implement an interface, they must provide the definition of behaviour. For e.g. if some one tries to implement a Flyable interface then every one should provide a definition of the fly method and should write down how should the implementing class ‘fly’.

A tip for differentiating between abstract class and interface.

Classes are nouns like Vehicle, Actor, Object etc and Interfaces are Adverbs like Runnable, Readable, Flyable etc.
See the word able that shows that it is to impart capabilities.

Here is a diagram to show the difference pictorially, Vehicle and Animal are abstract classes where as Flyable is an interface. Please notice the difference in the lines going to an interface and the line going to the abstract class.
diagram
The solid lines means extension (inheritance by extending classes), for e.g Bird extends Animal. The dotted line shows implementation (inheritance by implementing interfaces), for e.g. Aircraft implements Flyable.

At last I would like to highlight in what I believe about abstraction. Abstraction is not another feature of Object Oriented Programming, it is the result of the core feature i.e. Inheritance and it should be read as a part of inheritance and not as a separate feature because Inheritance is the reason why we have to use abstraction.

Conclusion

Here we learnt about using Abstract Classes And Interfaces, how and when it should be used and when to choose one over the other. We tried to develop a clear understanding about the reason behind having two different language constructs.

Hope this helps, happy reading. Stay connected and stay Subscribed

  • vijay shankar Singh

    super cool explanation and example!

  • Tushar Pande

    Very nicely explained… looking forward for more on OOP's concept 🙂

  • rajesh mallela

    Great post with clear understanding..Thanks a lot bro.

    • thank you Rajesh… Your feedback is much appreciated. You can help me by sharing it with your friends and colleague

      • rajesh mallela

        sure..