Why are interfaces preferred to abstract classes?

Question

I recently attended an interview and they asked me the question \"Why Interfaces are preferred over Abstract classes?\"

I tried giving a few answers like:

Answer 1

In general, and this is by no means a "rule" that should be blindly followed, the most flexible arrangement is:

interface
   abstract class
       concrete class 1       
       concrete class 2

The interface is there for a couple of reasons:

• an existing class that already extends something can implement the interface (assuming you have control over the code for the existing class)
• an existing class can be subclasses and the subclass can implement the interface (assuming the existing class is subclassable)

This means that you can take pre-existing classes (or just classes that MUST extend from something else) and have them work with your code.

The abstract class is there to provide all of the common bits for the concrete classes. The abstract class is extended from when you are writing new classes or modifying classes that you want to extend it (assuming they extend from java.lang.Object).

You should always (unless you have a really good reason not to) declare variables (instance, class, local, and method parameters) as the interface.

Answer 2

As devinb and others mention, it sounds like the interviewer shows their ignorance in not accepting your valid answers.

However, the mention of JDBC might be a hint. In that case, perhaps they are asking for the benefits of a client coding against an interface instead of a class.

So instead of perfectly valid answers such as "you only get one use of inheritance", which are relating to class design, they may be looking for an answer more like "decouples a client from a specific implementation".

Answer 3

Abstract classes have a number of potential pitfalls. For example, if you override a method, the super() method is not called unless you explicitly call it. This can cause problems for poorly-implemented overriding classes. Also, there are potential problems with equals() when you use inheritance.

Using interfaces can encourage use of composition when you want to share an implementation. Composition is very often a better way to reuse others objects, as it is less brittle. Inheritance is easily overused or used for the wrong purposes.

Defining an interface is a very safe way to define how an object is supposed to act, without risking the brittleness that can come with extending another class, abstract or not.

Also, as you mention, you can only extend one class at a time, but you can implement as many interfaces as you wish.

Answer 4

Because interfaces are not forcing you into some inheritance hierarchy.

Answer 5

You can implement more than one interface, but you can only inherit from a single class

Answer 6

That interview question reflects a certain belief of the person asking the question. I believe that the person is wrong, and therefore you can go one of two directions.

1. Give them the answer they want.
2. Respectfully disagree.

The answer that they want, well, the other posters have highlighted those incredibly well. Multiple interface inheritance, the inheritance forces the class to make implementation choices, interfaces can be changed easier.

However, if you create a compelling (and correct) argument in your disagreement, then the interviewer might take note. First, highlight the positive things about interfaces, this is a MUST. Secondly, I would say that interfaces are better in many scenarios, but they also lead to code duplication which is a negative thing. If you have a wide array of subclasses which will be doing largely the same implementation, plus extra functionality, then you might want an abstract class. It allows you to have many similar objects with fine grained detail, whereas with only interfaces, you must have many distinct objects with almost duplicate code.

Interfaces have many uses, and there is a compelling reason to believe they are 'better'. However you should always be using the correct tool for the job, and that means that you can't write off abstract classes.