Differences Between Abstract Class and Interface
Differences Between Abstract Class and Interface
When interviewing for developer positions, it's important to know the basic differences between abstract classes and interfaces.
Join the DZone community and get the full member experience.Join For Free
It is Obvious, Right?
No, it’s not. I have conducted a lot of interviews and very often one of the first questions I used to ask was the one about the differences between interface and abstract class. And still I met a lot of programmers who couldn’t give me the right answer.
In my opinion even a junior programmer should know them, maybe not necessarily with understanding what reasons lie behind, but still - structural differences, specific for a particular language (and the same for almost all OOP languages) should be more than known.
What do I find instead? Candidates who were applying for other positions (sometimes even senior ones) who didn’t know the differences or knew only a few or one.
I know that only the things that we know very well are easy, but those are OO basics and we have to know them to write well-designed code.
So, let’s talk about basics.
Let’s start with one of the most known differences between an interface and an abstract class. This difference is about inheritance – any class can implement many interfaces, but can extend only one class and can have only one parent.
Multiple classes extending is a language feature that is present in a few object-oriented languages. Why? Because it brings more problems than value.
When a class has many parents and there is a situation that we have exactly the same method’s declaration in more than one, we would have to explicitly “tell” which one is the one that interests us.
Such a code is difficult to maintain, because you have to carefully go through it whenever you are introducing any change or refactoring it. On the other hand, if one class would need to extend (at least) two classes with the same method then we are either talking about breaking DRY rule and we can extract something elsewhere, or we are messing with Single Responsibility Principle.
Well, we are messing with SRP if there’s a need of extending two classes. If each is responsible for one thing then something which has to extend both of them is responsible for… yeah, I believe you know what I mean.
“C’mon man, so if a multiple class inheritance is so bad, why is it ok to implement many interfaces?” – if a question like this appeared in your mind I have to admit that is a damn good question :)
Yet, the answer is simple. Every interface is based on a functionality as opposed to a class – on implementation. So, even if we are implementing ten different interfaces and each contains the same method’s declaration there’s no collision in it. Interface is a guarantee of method’s existence, not the way how it have to be implemented which means that as long as you aren’t violating SRP you should be ok with implementing many interfaces.
All methods in the interface are public, but there is no such rule for those declared in abstract classes. Those ones can have any visibility except private. Why not private? Because an abstract method needs to be implemented in subclass and private is not accessible from subclass. As you can see, those two ideas are mutually exclusive.
Ok, but let’s back to the main topic. As I wrote earlier, interface is a guarantee of a functionality, you can treat it as a contract between classes which is using interface and those classes which are implementing it. It’s a guarantee that a particular class will have all declared methods implemented. That’s why those methods must be public. Any other are not important at this moment, because are strictly related to implementation.
However, it’s not the case when we talk about abstract classes. We always can have group of classes which are different in just a few aspects and except this are pretty much the same and body of their public methods is also very similar. When we find ourselves in a situation like this we can always create protected method which will be place where differences will be kept. One of the popular pattern which is using this behavior is Template Method.
Declaration vs. Definition
Interface can contain only methods’ declarations and abstract class can contain also definition of the methods.
It’s like that because the interface is focused on providing specific functionality and abstract class can be focused also on similarity in implementations of subclasses, not only on their functionality.
Both in interfaces and abstract classes there’s no problem with defining constant values. It’s because those values doesn’t depend on particular object, but are the same for all of them.
Abstract classes can contain attributes while interfaces cannot. The reason is the same as with declarations and definitions.
Other than showing the differences, I also tried to explain the reasons it comes from. That it is not only because of whims of people who invented a particular language. It comes directly from ideas and concepts that stand behind those constructions.
I hope that I didn’t forget about anything. But if yes, then please bring it to my attention in your comments and I will try to remove mistakes as fast as I can.
And, well, good luck with your interviews :)
Published at DZone with permission of Sebastian Malaca , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.