Difference between abstract class with all method abstract and interface?

Question

I had an interview where interviewer asked me first what is the difference between abstract class with all the methods abstract and an interface.

I replied that if

Answer 1

For the first situation i'd chose interface over abstract class with all methods abstract as having interface leaves me with option in future for my implementing class to extend some other (abstract) class.

For second scenario, if you really don't want your concrete class to extend any other class and also want to "implement" contract, you can have abstract class with all methods abstract.

Answer 2

I can't say what your interviewer had in mind, but an interface is more of a "contract" whereas an abstract base class, while it can play that role too, is more geared towards hierarchies or IS-A relationships. E.g. an Apple IS-A Fruit, a Pear IS-A Fruit, etc. But you're right, they could well be used interchangeably for practical purposes in that context, but an OO purist might not want to use an abstract class unless they were expressing IS-A relationship(s).

Answer 3

Here are the differences:

1. A class can extend exactly abstract class, but can implement any number of interfaces.
2. An abstract class can have protected, private (does not apply to your question), package, and public methods, but an interface can only have public methods.
3. An abstract class can have instance variables (often called data members or properties) while an interface can only have static variables.

The answer to the question: "blah never extend blah implement contract blah" is this: "I would use an abstract class if I did needed instance variables and/or non-public methods and otherwise I would use an interface".

Answer 4

The answer stating that an interface represents a contract is not acceptable. That's the answer we give to Junior since it may be too complex to clearly figure out the difference between the essence of an abstract class and the essence of an interface without much architecture experience and without reading a lot of classic books about. Any abstract class with public methods acts as a contract, as well as an interface.

An abstract class that doesn't provide any implementation is in 99% of cases a representation of an object's Role.
An interface represents a Role.
Each object might have several different roles that shouldn't be tied together but composed by the concerned object.

I'm explaining this with this example:

Your interviewer could say:
I have a Robot that can walk and a Human that can walk too.

So based on this case, he asks you: should I extract the walking feature in an abstract base class or in an interface, knowing that the implementations have nothing in common?

You think..."oh I know so: in this case, having one abstract class with an abstract method walk(), then is clearly the same than declaring an interface with the walk() method."
So your answer would surely be: "it's the choice of the developer !".
And it's really not an always valid answer.

Why? Let's see the next expectation:
A Human can eat, but obviously the Robot cannot and even doesn't need.

What if you implemented the walking feature with an abstract class? You would end up with:

public abstract class Biped {  
  public void abstract walk();
} 

public Robot extends Biped {
   public void walk() {
     //walk at 10km/h speed
   }
}

public Human extends Biped {
   public void walk() {
     //walk at 5km/h speed
   }
}

How could you plug the eating feature? You're stuck because you can't implement it in the Biped base class since it would break Liskov Substitution Principle, since a Robot doesn't eat! And you can't expect Human extending another base class due to the known Java rule.

Of course, you could add a specific Feedable interface only dedicated to Human:

public interface Feedable {
  void eat();
} 

Signature becomes: public Human extends Biped implements Feedable { Clearly, it makes no sense and confusing to have one role implemented through a class and the other through an interface.

That's why starting with interface is really preferred whenever we have the choice.

With an interface, we can model Roles easily by composing.

So the final solution would then be:

public interface Walkable {
   void abstract walk();
} 

public interface Feedable {
   void eat();
} 

public Robot implements Walkable {
   public void walk() {
     //walk at 10km/h speed
   }
}

public Human implements Walkable, Feedable {
   public void walk() {
     //walk at 5km/h speed
   }

   public void eat(){
     //...
   }    
}

Doesn't it remind you the Interface Segregation Principle? ;)

To sum up, if you specify an IS-A relationship, uses an abstract class. If you realize that you are about to model a Role (let's say a IS-CAPABLE-OF relationship), go with interface.

Answer 5

Interfaces are the natural way of creating a contract because they force you to implement the methods they define.

Besides that, you can implement as many as you want in the case you want to add new interfaces to your class.

Answer 6

One thing to keep in mind is be the ability to have diamond inheritance for interfaces.

Consider this interface hierarchy:

interface Base{}

interface Sub1 extends Base{}

interface Sub2 extends Base{}

interface SubSub extends Sub1, Sub2{}

The same wouldn't be possible with abstract classes:

abstract class Base{}

abstract class Sub1 extends Base{}

abstract class Sub2 extends Base{}

// NOT ALLOWED! can only extend one class
// abstract class SubSub extends Sub1, Sub2{}

This is something that would be allowed in C++ (although tricky to get right). I think he might have been fishing for this. In general, this is the ultimate reason why I always try to write interface hierarchies instead of class hierarchies.