Home » Java » How should I have explained the difference between an Interface and an Abstract class?

How should I have explained the difference between an Interface and an Abstract class?

Posted by: admin November 2, 2017 Leave a comment


In one of my interviews, I have been asked to explain the difference between an Interface and an Abstract class.

Here’s my response:

Methods of a Java interface are implicitly abstract
and cannot have implementations. A Java abstract class can have
instance methods that implements a default behaviour.

Variables declared in a Java interface are by default final. An
abstract class may contain non-final variables.

Members of a Java interface are public by default. A Java abstract
class can have the usual flavours of class members like private,
protected, etc.

A Java interface should be implemented using keyword “implements”; A
Java abstract class should be extended using keyword “extends”.

An interface can extend another Java interface only, an abstract class
can extend another Java class and implement multiple Java interfaces.

A Java class can implement multiple interfaces but it can extend only
one abstract class.

However, the interviewer was not satisfied, and told me that this description represented “bookish knowledge“.

He asked me for a more practical response, explaining when I would choose an abstract class over an interface, using practical examples.

Where did I go wrong?


I will give you an example first:

public interface LoginAuth{
   public String encryptPassword(String pass);
   public void checkDBforUser();

Now suppose you have 3 databases in your application. Then each and every implementation for that database needs to define the above 2 methods:

public class DBMySQL implements LoginAuth{
          // Needs to implement both methods
public class DBOracle implements LoginAuth{
          // Needs to implement both methods
public class DBAbc implements LoginAuth{
          // Needs to implement both methods

But what if encryptPassword() is not database dependent, and it’s the same for each class? Then the above would not be a good approach.

Instead, consider this approach:

public abstract class LoginAuth{
   public String encryptPassword(String pass){
            // Implement the same default behavior here 
            // that is shared by all subclasses.

   // Each subclass needs to provide their own implementation of this only:
   public abstract void checkDBforUser();

Now in each child class, we only need to implement one method – the method that is database dependent.

I tried my best and Hope this will clear your doubts.


Nothing is perfect in this world. They may have been expecting more of a practical approach.

But after your explanation you could add these lines with a slightly different approach.

  1. Interfaces are rules (rules because you must give an implementation to them that you can’t ignore or avoid, so that they are imposed like rules) which works as a common understanding document among various teams in software development.

  2. Interfaces give the idea what is to be done but not how it will be done. So implementation completely depends on developer by following the given rules (means given signature of methods).

  3. Abstract classes may contain abstract declarations, concrete implementations, or both.

  4. Abstract declarations are like rules to be followed and concrete implementations are like guidelines (you can use it as it is or you can ignore it by overriding and giving your own implementation to it).

  5. Moreover which methods with same signature may change the behaviour in different context are provided as interface declarations as rules to implement accordingly in different contexts.


You made a good summary of the practical differences in use and implementation but did not say anything about the difference in meaning.

An interface is a description of the behaviour an implementing class will have. The implementing class ensures, that it will have these methods that can be used on it. It is basically a contract or a promise the class has to make.

An abstract class is a basis for different subclasses that share behaviour which does not need to be repeatedly created. Subclasses must complete the behaviour and have the option to override predefined behaviour (as long as it is not defined as final or private).

You will find good examples in the java.util package which includes interfaces like List and abstract classes like AbstractList which already implements the interface. The official documentation describes the AbstractList as follows:

This class provides a skeletal implementation of the List interface to minimize the effort required to implement this interface backed by a “random access” data store (such as an array).


An interface consists of singleton variables (public static final) and public abstract methods. We normally prefer to use an interface in real time when we know what to do but don’t know how to do it.

This concept can be better understood by example:

Consider a Payment class. Payment can be made in many ways, such as PayPal, credit card etc. So we normally take Payment as our interface which contains a makePayment() method and CreditCard and PayPal are the two implementation classes.

public interface Payment
    void makePayment();//by default it is a abstract method
public class PayPal implements Payment
    public void makePayment()
        //some logic for PayPal payment
        //e.g. Paypal uses username and password for payment
public class CreditCard implements Payment
    public void makePayment()
        //some logic for CreditCard payment
        //e.g. CreditCard uses card number, date of expiry etc...

In the above example CreditCard and PayPal are two implementation classes /strategies. An Interface also allows us the concept of multiple inheritance in Java which cannot be accomplished by an abstract class.

We choose an abstract class when there are some features for which we know what to do, and other features that we know how to perform.

Consider the following example:

public abstract class Burger
    public void packing()
        //some logic for packing a burger
    public abstract void price(); //price is different for different categories of burgers
public class VegBerger extends Burger
    public void price()
        //set price for a veg burger.
public class NonVegBerger extends Burger
    public void price()
        //set price for a non-veg burger.

If we add methods (concrete/abstract) in the future to a given abstract class, then the implementation class will not need a change its code. However, if we add methods in an interface in the future, we must add implementations to all classes that implemented that interface, otherwise compile time errors occur.

There are other differences but these are major ones which may have been what your interviewer expected . Hopefully this was helpful.


All your statements are valid except your first statement (after the Java 8 release):

Methods of a Java interface are implicitly abstract and cannot have implementations

From the documentation page:

An interface is a reference type, similar to a class, that can contain only
constants, method signatures, default methods, static methods,and nested types

Method bodies exist only for default methods and static methods.

Default methods:

An interface can have default methods, but are different than abstract methods in abstract classes.

Default methods enable you to add new functionality to the interfaces of your libraries and ensure binary compatibility with code written for older versions of those interfaces.

When you extend an interface that contains a default method, you can do the following:

  1. Not mention the default method at all, which lets your extended interface inherit the default method.
  2. Redeclare the default method, which makes it abstract.
  3. Redefine the default method, which overrides it.

Static Methods:

In addition to default methods, you can define static methods in interfaces. (A static method is a method that is associated with the class in which it is defined rather than with any object. Every instance of the class shares its static methods.)

This makes it easier for you to organize helper methods in your libraries;

Example code from documentation page about interface having static and default methods.

import java.time.*;

public interface TimeClient {
    void setTime(int hour, int minute, int second);
    void setDate(int day, int month, int year);
    void setDateAndTime(int day, int month, int year,
                               int hour, int minute, int second);
    LocalDateTime getLocalDateTime();

    static ZoneId getZoneId (String zoneString) {
        try {
            return ZoneId.of(zoneString);
        } catch (DateTimeException e) {
            System.err.println("Invalid time zone: " + zoneString +
                "; using default time zone instead.");
            return ZoneId.systemDefault();

    default ZonedDateTime getZonedDateTime(String zoneString) {
        return ZonedDateTime.of(getLocalDateTime(), getZoneId(zoneString));

Use the below guidelines to chose whether to use an interface or abstract class.


  1. To define a contract ( preferably stateless – I mean no variables )
  2. To link unrelated classes with has a capabilities.
  3. To declare public constant variables (immutable state)

Abstract class:

  1. Share code among several closely related classes. It establishes is a relation.

  2. Share common state among related classes ( state can be modified in concrete classes)

Related posts:

Interface vs Abstract Class (general OO)

Implements vs extends: When to use? What's the difference?

By going through these examples, you can understand that

Unrelated classes can have capabilities through interface but related classes change the behaviour through extension of base classes.


Difference between Abstact class and interface

  1. Abstract classes versus interfaces in Java 8
  2. Conceptual Difference:

Interface Default Methods in Java 8

  1. What is Default Method?
  2. ForEach method compilation error solved using Default Method
  3. Default Method and Multiple Inheritance Ambiguity Problems
  4. Important points about java interface default methods:

Java Interface Static Method

  1. Java Interface Static Method, code example, static method vs default method
  2. Important points about java interface static method:

Java Functional Interfaces

Abstract classes versus interfaces in Java 8

Java 8 interface changes include static methods and default methods in
interfaces. Prior to Java 8, we could have only method declarations in
the interfaces. But from Java 8, we can have default methods and
static methods in the interfaces.

After introducing Default Method, it seems that interfaces and
abstract classes are same. However, they are still different concept
in Java 8.

Abstract class can define constructor. They are more structured and
can have a state associated with them. While in contrast, default
method can be implemented only in the terms of invoking other
interface methods, with no reference to a particular implementation’s
state. Hence, both use for different purposes and choosing between two
really depends on the scenario context.

Conceptual Difference:

Abstract classes are valid for skeletal (i.e. partial) implementations of interfaces but should not exist without a matching interface.

So when abstract classes are effectively reduced to be low-visibility, skeletal implementations of interfaces, can default methods take this away as well? Decidedly: No! Implementing interfaces almost always requires some or all of those class-building tools which default methods lack. And if some interface doesn’t, it is clearly a special case, which should not lead you astray.

Interface Default Methods in Java 8

Java 8 introduces “Default Method” or (Defender methods) new feature, which allows developer to add new methods to the Interfaces without breaking the existing implementation of these Interface. It provides flexibility to allow Interface define implementation which will use as default in the situation where a concrete Class fails to provide an implementation for that method.

Let consider small example to understand how it works:

public interface OldInterface {
    public void existingMethod();
    default public void newDefaultMethod() {
        System.out.println("New default method"
               + " is added in interface");

The following Class will compile successfully in Java JDK 8,

public class OldInterfaceImpl implements OldInterface {
    public void existingMethod() {
     // existing implementation is here…

If you create an instance of OldInterfaceImpl:

OldInterfaceImpl obj = new OldInterfaceImpl ();
// print “New default method add in interface”

Default Method:

Default methods are never final, can not be synchronized and can not
override Object’s methods. They are always public, which severely
limits the ability to write short and reusable methods.

Default methods can be provided to an Interface without affecting implementing Classes as it includes an implementation. If each added method in an Interface defined with implementation then no implementing Class is affected. An implementing Class can override the default implementation provided by the Interface.

Default methods enable to add new functionality to existing Interfaces
without breaking older implementation of these Interfaces.

When we extend an interface that contains a default method, we can perform following,

  1. Not override the default method and will inherit the default method.
  2. Override the default method similar to other methods we override in
  3. Redeclare default method as abstract, which force subclass to
    override it.

ForEach method compilation error solved using Default Method

For Java 8, the JDK collections have been extended and forEach method is added to the entire collection (which work in conjunction with lambdas). With conventional way, the code looks like below,

public interface Iterable<T> {
    public void forEach(Consumer<? super T> consumer);

Since this result each implementing Class with compile errors therefore, a default method added with a required implementation in order that the existing implementation should not be changed.

The Iterable Interface with the Default method is below,

public interface Iterable<T> {
    public default void forEach(Consumer
                   <? super T> consumer) {
        for (T t : this) {

The same mechanism has been used to add Stream in JDK Interface without breaking the implementing Classes.

Default Method and Multiple Inheritance Ambiguity Problems

Since java Class can implement multiple Interfaces and each Interface can define default method with same method signature, therefore, the inherited methods can conflict with each other.

Consider below example,

public interface InterfaceA {  
       default void defaultMethod(){  
           System.out.println("Interface A default method");  
public interface InterfaceB {
   default void defaultMethod(){
       System.out.println("Interface B default method");
public class Impl implements InterfaceA, InterfaceB  {

The above code will fail to compile with the following error,

java: class Impl inherits unrelated defaults for defaultMethod() from
types InterfaceA and InterfaceB

In order to fix this class, we need to provide default method implementation:

public class Impl implements InterfaceA, InterfaceB {
    public void defaultMethod(){

Further, if we want to invoke default implementation provided by any of super Interface rather than our own implementation, we can do so as follows,

public class Impl implements InterfaceA, InterfaceB {
    public void defaultMethod(){
        // existing code here..

We can choose any default implementation or both as part of our new method.

Important points about java interface default methods:

  1. Java interface default methods will help us in extending interfaces without having the fear of breaking implementation classes.
  2. Java interface default methods has bridge down the differences between interfaces and abstract classes.
  3. Java 8 interface default methods will help us in avoiding utility classes, such as all the Collections class method can be provided in the interfaces itself.
  4. Java interface default methods will help us in removing base implementation classes, we can provide default implementation and the implementation classes can chose which one to override.
  5. One of the major reason for introducing default methods in interfaces is to enhance the Collections API in Java 8 to support lambda expressions.
  6. If any class in the hierarchy has a method with same signature, then default methods become irrelevant. A default method cannot override a method from java.lang.Object. The reasoning is very simple, it’s because Object is the base class for all the java classes. So even if we have Object class methods defined as default methods in interfaces, it will be useless because Object class method will always be used. That’s why to avoid confusion, we can’t have default methods that are overriding Object class methods.
  7. Java interface default methods are also referred to as Defender Methods or Virtual extension methods.

Resource Link:

  1. Interface with default methods vs Abstract class in Java 8
  2. Abstract class versus interface in the JDK 8 era
  3. Interface evolution via virtual extension methods

Java Interface Static Method

Java Interface Static Method, code example, static method vs default method

Java interface static method is similar to default method except that we can’t override them in the implementation classes. This feature helps us in avoiding undesired results incase of poor implementation in implementation classes. Let’s look into this with a simple example.

public interface MyData {

    default void print(String str) {
        if (!isNull(str))
            System.out.println("MyData Print::" + str);

    static boolean isNull(String str) {
        System.out.println("Interface Null Check");

        return str == null ? true : "".equals(str) ? true : false;

Now let’s see an implementation class that is having isNull() method with poor implementation.

public class MyDataImpl implements MyData {

    public boolean isNull(String str) {
        System.out.println("Impl Null Check");

        return str == null ? true : false;

    public static void main(String args[]){
        MyDataImpl obj = new MyDataImpl();

Note that isNull(String str) is a simple class method, it’s not overriding the interface method. For example, if we will add @Override annotation to the isNull() method, it will result in compiler error.

Now when we will run the application, we get following output.

Interface Null Check

Impl Null Check

If we make the interface method from static to default, we will get following output.

Impl Null Check

MyData Print::

Impl Null Check

Java interface static method is visible to interface methods only, if we remove the isNull() method from the MyDataImpl class, we won’t be able to use it for the MyDataImpl object. However like other static methods, we can use interface static methods using class name. For example, a valid statement will be:

boolean result = MyData.isNull("abc");

Important points about java interface static method:

  1. Java interface static method is part of interface, we can’t use it for implementation class objects.
  2. Java interface static methods are good for providing utility methods, for example null check, collection sorting etc.
  3. Java interface static method helps us in providing security by not allowing implementation classes to override them.
  4. We can’t define interface static method for Object class methods, we will get compiler error as “This static method cannot hide the instance method from Object”. This is because it’s not allowed in java, since Object is the base class for all the classes and we can’t have one class level static method and another instance method with same signature.
  5. We can use java interface static methods to remove utility classes such as Collections and move all of it’s static methods to the corresponding interface, that would be easy to find and use.

Java Functional Interfaces

Before I conclude the post, I would like to provide a brief introduction to Functional interfaces. An interface with exactly one abstract method is known as Functional Interface.

A new annotation @FunctionalInterface has been introduced to mark an interface as Functional Interface. @FunctionalInterface annotation is a facility to avoid accidental addition of abstract methods in the functional interfaces. It’s optional but good practice to use it.

Functional interfaces are long awaited and much sought out feature of Java 8 because it enables us to use lambda expressions to instantiate them. A new package java.util.function with bunch of functional interfaces are added to provide target types for lambda expressions and method references. We will look into functional interfaces and lambda expressions in the future posts.

Resource Location:

  1. Java 8 Interface Changes – static method, default method

Your explanation looks decent, but may be it looked like you were reading it all from a textbook? :-/

What I’m more bothered about is, how solid was your example? Did you bother to include almost all the differences between abstract and interfaces?

Personally, I would suggest this link:

for an exhaustive list of differences..

Hope it helps you and all other readers in their future interviews


Many junior developers make the mistake of thinking of interfaces, abstract and concrete classes as slight variations of the same thing, and choose one of them purely on technical grounds: Do I need multiple inheritance? Do I need some place to put common methods? Do I need to bother with something other than just a concrete class? This is wrong, and hidden in these questions is the main problem: “I”. When you write code for yourself, by yourself, you rarely think of other present or future developers working on or with your code.

Interfaces and abstract classes, although apparently similar from a technical point of view, have completely different meanings and purposes.


  1. An interface defines a contract that some implementation will fulfill for you.

  2. An abstract class provides a default behavior that your implementation can reuse.

These two points above is what I’m looking for when interviewing, and is a compact enough summary. Read on for more details.

Alternative summary

  1. An interface is for defining public APIs
  2. An abstract class is for internal use, and for defining SPIs

By example

To put it differently: A concrete class does the actual work, in a very specific way. For example, an ArrayList uses a contiguous area of memory to store a list of objects in a compact manner which offers fast random access, iteration, and in-place changes, but is terrible at insertions, deletions, and occasionally even additions; meanwhile, a LinkedList uses double-linked nodes to store a list of objects, which instead offers fast iteration, in-place changes, and insertion/deletion/addition, but is terrible at random access. These two types of lists are optimized for different use cases, and it matters a lot how you’re going to use them. When you’re trying to squeeze performance out of a list that you’re heavily interacting with, and when picking the type of list is up to you, you should carefully pick which one you’re instantiating.

On the other hand, high level users of a list don’t really care how it is actually implemented, and they should be insulated from these details. Let’s imagine that Java didn’t expose the List interface, but only had a concrete List class that’s actually what LinkedList is right now. All Java developers would have tailored their code to fit the implementation details: avoid random access, add a cache to speed up access, or just reimplement ArrayList on their own, although it would be incompatible with all the other code that actually works with List only. That would be terrible… But now imagine that the Java masters actually realize that a linked list is terrible for most actual use cases, and decided to switch over to an array list for their only List class available. This would affect the performance of every Java program in the world, and people wouldn’t be happy about it. And the main culprit is that implementation details were available, and the developers assumed that those details are a permanent contract that they can rely on. This is why it’s important to hide implementation details, and only define an abstract contract. This is the purpose of an interface: define what kind of input a method accepts, and what kind of output is expected, without exposing all the guts that would tempt programmers to tweak their code to fit the internal details that might change with any future update.

An abstract class is in the middle between interfaces and concrete classes. It is supposed to help implementations share common or boring code. For example, AbstractCollection provides basic implementations for isEmpty based on size is 0, contains as iterate and compare, addAll as repeated add, and so on. This lets implementations focus on the crucial parts that differentiate between them: how to actually store and retrieve data.

Another perspective: APIs versus SPIs

Interfaces are low-cohesion gateways between different parts of code. They allow libraries to exist and evolve without breaking every library user when something changes internally. It’s called Application Programming Interface, not Application Programming Classes. On a smaller scale, they also allow multiple developers to collaborate successfully on large scale projects, by separating different modules through well documented interfaces.

Abstract classes are high-cohesion helpers to be used when implementing an interface, assuming some level of implementation details. Alternatively, abstract classes are used for defining SPIs, Service Provider Interfaces.

The difference between an API and an SPI is subtle, but important: for an API, the focus is on who uses it, and for an SPI the focus is on who implements it.

Adding methods to an API is easy, all existing users of the API will still compile. Adding methods to an SPI is hard, since every service provider (concrete implementation) will have to implement the new methods. If interfaces are used to define an SPI, a provider will have to release a new version whenever the SPI contract changes. If abstract classes are used instead, new methods could either be defined in terms of existing abstract methods, or as empty throw not implemented exception stubs, which will at least allow an older version of a service implementation to still compile and run.

A note on Java 8 and default methods

Although Java 8 introduced default methods for interfaces, which makes the line between interfaces and abstract classes even blurrier, this wasn’t so that implementations can reuse code, but to make it easier to change interfaces that serve both as an API and as an SPI (or are wrongly used for defining SPIs instead of abstract classes).

“Book knowledge”

The technical details provided in the OP’s answer are considered “book knowledge” because this is usually the approach used in school and in most technology books about a language: what a thing is, not how to use it in practice, especially in large scale applications.

Here’s an analogy: supposed the question was:

What is better to rent for prom night, a car or a hotel room?

The technical answer sounds like:

Well, in a car you can do it sooner, but in a hotel room you can do it more comfortably. On the other hand, the hotel room is in only one place, while in the car you can do it in more places, like, let’s say you can go to the vista point for a nice view, or in a drive-in theater, or many other places, or even in more than one place. Also, the hotel room has a shower.

That is all true, but completely misses the points that they are two completely different things, and both can be used at the same time for different purposes, and the “doing it” aspect is not the most important thing about either of the two options. The answer lacks perspective, it shows an immature way of thinking, while correctly presenting true “facts”.


An interface is a “contract” where the class that implements the contract promises to implement the methods. An example where I had to write an interface instead of a class was when I was upgrading a game from 2D to 3D. I had to create an interface to share classes between the 2D and the 3D version of the game.

package adventure;
import java.awt.*;
public interface Playable {
    public void playSound(String s);
    public Image loadPicture(String s);    

Then I can implement the methods based on the environment, while still being able to call those methods from an object that doesn’t know which version of the game that is loading.

public class Adventure extends JFrame implements Playable

public class Dungeon3D extends SimpleApplication implements Playable

public class Main extends SimpleApplication implements AnimEventListener,
ActionListener, Playable

Typically, in the gameworld, the world can be an abstract class that performs methods on the game:

public abstract class World...

    public Playable owner;

    public Playable getOwner() {
        return owner;

    public void setOwner(Playable owner) {
        this.owner = owner;


What about thinking the following way:

  • A relationship between a class and an abstract class is of type “is-a”
  • A relationship between a class and an interface is of type “has-a”

So when you have an abstract class Mammals, a subclass Human, and an interface Driving, then you can say

  • each Human is-a Mammal
  • each Human has-a Driving (behavior)

My suggestion is that the book knowledge phrase indicates that he wanted to hear the semantic difference between both (like others here already suggested).


Abstract classes are meant to be inherited from, and when one class inherits from another it means that there is a strong relationship between the 2 classes.
With an interface on the other hand, the relationship between the interface itself and the class implementing the interface is not necessarily strong.
So, we can summarize this first point by saying that an abstract class would be more appropriate when there is a strong relationship between the abstract class and the classes that will derive from it. Again, this is because an abstract class is very closely linked to inheritance, which implies a strong relationship. But, with interfaces there need not be a strong relationship between the interface and the classes that implement the interface.
Java interface can extend multiple interface also Java class can implement multiple interfaces, Which means interface can provide more polymorphism support than abstract class . By extending abstract class, a class can only participate in one Type hierarchy but by using interface it can be part of multiple type hierarchies.

In order to implement interface in Java, until your class is abstract, you need to provide implementation of all methods, which is very painful. On the other hand abstract class may help you in this case by providing default implementation.


Abstract classes are not pure abstraction bcz its collection of concrete(implemented methods) as well as unimplemented methods.
Interfaces are pure abstraction bcz there are only unimplemented methods not concrete methods.

Why Abstract classes?

  1. If user want write common functionality for all objects.
  2. Abstract classes are best choice for reimplementation in future that to add more functionality without affecting of end user.

Why Interfaces?

  1. If user want to write different functionality that would be different functionality on objects.
  2. Interfaces are best choice that if not need to modify the requirements once interface has been published.

The main difference what i have observed was that abstract class provides us with some common behaviour implemented already and subclasses only needs to implement specific functionality corresponding to them. where as for an interface will only specify what tasks needs to be done and no implementations will be given by interface. I can say it specifies the contract between itself and implemented classes.


I do interviews for work and i would look unfavourably on your answer aswell (sorry but im very honest). It does sound like you’ve read about the difference and revised an answer but perhaps you have never used it in practice.

A good explanation as to why you would use each can be far better than having a precise explanation of the difference. Employers ultimatley want programers to do things not know them which can be hard to demonstrate in an interview. The answer you gave would be good if applying for a technical or documentation based job but not a developers role.

Best of luck with interviews in the future.

Also my answer to this question is more about interview technique rather than the technical material youve provided. Perhaps consider reading about it. https://workplace.stackexchange.com/ can be an excellent place for this sort of thing.


An interface is like a set of genes that are publicly documented to have some kind of effect: A DNA test will tell me whether I’ve got them – and if I do, I can publicly make it known that I’m a “carrier” and part of my behavior or state will conform to them. (But of course, I may have many other genes that provide traits outside this scope.)

An abstract class is like the dead ancestor of a single-sex species(*): She can’t be brought to life but a living (i.e. non-abstract) descendant inherits all her genes.

(*) To stretch this metaphor, let’s say all members of the species live to the same age. This means all ancestors of a dead ancestor must also be dead – and likewise, all descendants of a living ancestor must be alive.


An interface is purely abstract. we dont have any implementation code in interface.

Abstract class contains both methods and its implementation.

click here to watch tutorial on interfaces and abstract classes


The main difference what i have observed was that abstract class provides us with some common behaviour implemented already and subclasses only needs to implement specific functionality corresponding to them. where as for an interface will only specify what tasks needs to be done and no implementations will be given by interface. I can say it specifies the contract between itself and implemented classes.


You choose Interface in Java to avoid the Diamond Problem in multiple inheritance.

If you want all of your methods to be implemented by your client you go for interface. It means you design the entire application at abstract.

You choose abstract class if you already know what is in common. For example Take an abstract class Car. At higher level you implement the common car methods like calculateRPM(). It is a common method and you let the client implement his own behavior like
calculateMaxSpeed() etc. Probably you would have explained by giving few real time examples which you have encountered in your day to day job.


Even I have faced the same question in multiple interviews and believe me it makes your time miserable to convince the interviewer.
If I inherent all the answers from above then I need to add one more key point to make it more convincing and utilizing OO at its best

In case you are not planning any modification in the rules , for the subclass to be followed, for a long future, go for the interface, as you wont be able to modify in it and if you do so, you need to go for the changes in all the other sub classes, whereas, if you think, you want to reuse the functionality, set some rules and also make it open for modification, go for Abstract class.

Think in this way, you had used a consumable service or you had provided some code to world and You have a chance to modify something, suppose a security check
And If I am being a consumer of the code and One morning after a update , I find all read marks in my Eclipse, entire application is down.
So to prevent such nightmares, use Abstract over Interfaces

I think this might convince the Interviewer to a extent…Happy Interviews Ahead.


From what I understand, an Interface, which is comprised of final variables and methods with no implementations, is implemented by a class to obtain a group of methods or methods that are related to each other. On the other hand, an abstract class, which can contain non-final variables and methods with implementations, is usually used as a guide or as a superclass from which all related or similar classes inherits from. In other words, an abstract class contains all the methods/variables that are shared by all its subclasses.


In abstract class, you can write default implementation of methods! But in Interface you can not. Basically, In interface there exist pure virtual methods which have to be implemented by the class which implements the interface.


hmm now the people are hungery practical approach, you are quite right but most of interviewer looks as per their current requirment and want a practical approach.

after finishing your answer you should jump on the example:


for example we have salary function which have some parametar common to all employee. then we can have a abstract class called CTC with partialy defined method body and it will got extends by all type of employee and get redeined as per their extra beefits.
For common functonality.

public abstract class CTC {

    public int salary(int hra, int da, int extra)
        int total;
        total = hra+da+extra;
        //incentive for specific performing employee
        //total = hra+da+extra+incentive;
        return total;

class Manger extends CTC

class CEO extends CTC

class Developer extends CTC


interface in java allow to have interfcae functionality without extending that one and you have to be clear with the implementation of signature of functionality that you want to introduce in your application. it will force you to have definiton.
For different functionality.
public interface EmployeType {

    public String typeOfEmployee();

class ContarctOne implements EmployeType

    public String typeOfEmployee() {
        return "contract";


class PermanentOne implements EmployeType

    public String typeOfEmployee() {
        return "permanent";


you can have such forced activity with abstract class too by defined methgos as a abstract one, now a class tha extends abstract class remin abstract one untill it override that abstract function.


When I am trying to share behavior between 2 closely related classes, I create an abstract class that holds the common behavior and serves as a parent to both classes.

When I am trying to define a Type, a list of methods that a user of my object can reliably call upon, then I create an interface.

For example, I would never create an abstract class with 1 concrete subclass because abstract classes are about sharing behavior. But I might very well create an interface with only one implementation. The user of my code won’t know that there is only one implementation. Indeed, in a future release there may be several implementations, all of which are subclasses of some new abstract class that didn’t even exist when I created the interface.

That might have seemed a bit too bookish too (though I have never seen it put that way anywhere that I recall). If the interviewer (or the OP) really wanted more of my personal experience on that, I would have been ready with anecdotes of an interface has evolved out of necessity and visa versa.

One more thing. Java 8 now allows you to put default code into an interface, further blurring the line between interfaces and abstract classes. But from what I have seen, that feature is overused even by the makers of the Java core libraries. That feature was added, and rightly so, to make it possible to extend an interface without creating binary incompatibility. But if you are making a brand new Type by defining an interface, then the interface should be JUST an interface. If you want to also provide common code, then by all means make a helper class (abstract or concrete). Don’t be cluttering your interface from the start with functionality that you may want to change.


I will try to answer using practical scenario to show the distinction between the two.

Interfaces come with zero payload i.e. no state has to be maintained and thus are better choice to just associate a contract (capability) with a class.

For example, say I have a Task class that performs some action, now to execute a task in separate thread I don’t really need to extend Thread class rather better choice is to make Task implement Runnable interface (i.e. implement its run() method) and then pass object of this Task class to a Thread instance and call its start() method.

Now you can ask what if Runnable was a abstract class?

Well technically that was possible but design wise that would have been a poor choice reason being:

  • Runnable has no state associated with it and neither it ‘offers’ any
    default implementation for the run() method
  • Task would have to extend it thus it couldn’t extend any other class
  • Task has nothing to offer as specialization to Runnable class, all it needs is to override run() method

In other words, Task class needed a capability to be run in a thread which it achieved by implementing Runnable interface verses extending the Thread class that would make it a thread.

Simply put us interface to define a capability (contract), while use a
abstract class to define skeleton (common/partial) implementation of

Disclaimer: silly example follows, try not to judge 😛

interface Forgiver {
    void forgive();

abstract class GodLike implements Forgiver {
    abstract void forget();
    final void forgive() {

Now you have been given a choice to be GodLike but you may choose to be Forgiver only (i.e. not GodLike) and do:

class HumanLike implements Forgiver {
    void forgive() {
       // forgive but remember    

Or you may may choose to be GodLike and do:

class AngelLike extends GodLike {
    void forget() {
       // forget to forgive     

P.S. with java 8 interface can also have static as well default (overridable implementation) methods and thus difference b/w interface and abstract class is even more narrowed down.


Almost everything seems to be covered here already.. Adding just one more point on practical implementation of abstract class:

abstract keyword is also used just prevent a class from being instantiated. If you have a concrete class which you do not want to be instantiated – Make it abstract.


From what I understand and how I approach,

Interface is like a specification/contract, any class that implements a interface class have to implement all the methods defined in the abstract class (except default methods (introduced in java 8))

Whereas I define a class abstract when I know the implementation required for some methods of the class and some methods I still do not know what will be the implementation(we might know the function signature but not the implementation). I do this so that later in the part of development when i know how these methods are to be implemented, i can just extend this abstract class and implement these methods.

Note: You cannot have function body in interface methods unless the method is static or default.


I believe what the interviewer was trying to get at was probably the difference between interface and implementation.

The interface – not a Java interface, but “interface” in more general terms – to a code module is, basically, the contract made with client code that uses the interface.

The implementation of a code module is the internal code that makes the module work. Often you can implement a particular interface in more than one different way, and even change the implementation without client code even being aware of the change.

A Java interface should only be used as an interface in the above generic sense, to define how the class behaves for the benefit of client code using the class, without specifying any implementation. Thus, an interface includes method signatures – the names, return types, and argument lists – for methods expected to be called by client code, and in principle should have plenty of Javadoc for each method describing what that method does. The most compelling reason for using an interface is if you plan to have multiple different implementations of the interface, perhaps selecting an implementation depending on deployment configuration.

A Java abstract class, in contrast, provides a partial implementation of the class, rather than having a primary purpose of specifying an interface. It should be used when multiple classes share code, but when the subclasses are also expected to provide part of the implementation. This permits the shared code to appear in only one place – the abstract class – while making it clear that parts of the implementation are not present in the abstract class and are expected to be provided by subclasses.


your answer is right but the interviewer needs you to differentiate according to software engineering perspective not according to the details of Java.

Simple words:

An Interface is like the interface of a shop anything that is shown on it should be there in the shop, so any method in the Interface must be there implemented in the concrete class. Now what if some classes share some exact methods and varies in others. Suppose the Interface is about a shop that contains two things and suppose we have two shops both contain sport equipment but one has clothes extra and the other has shoes extra. So what you do is making an abstract class for Sport that implements the Sports method and leave the other method unimplemented. Abstract class here means that this shop doesn’t exist itself but it is the base for other classes/shops. This way you are organising the code, avoiding errors of replicating the code, unifying the code, and ensuring re-usability by some other class.


Your answer is ok, but I think he was looking for this kind of answer:

Abstract class

  • Abstract class can have abstract and non-abstract methods.
  • Abstract class doesn’t support multiple inheritance.
  • Abstract class can have final, non-final, static and non-static variables.
  • Abstract class can provide the implementation of interface.


  • Interface can have default, static and abstract methods.
  • Interface supports multiple inheritance.
  • Interface has only static and final variables.
  • Interface can’t provide the implementation of abstract class.

Yes, your responses were technically correct but where you went wrong was not showing them you understand the upsides and downsides of choosing one over the other. Additionally, they were probably concerned/freaked out about compatibility of their codebase with upgrades in the future. This type of response may have helped (in addition to what you said):

“Choosing an Abstract Class over an Interface Class depends on what we
project the future of the code will be.

Abstract classes allow better forward-compatibility because you can
continue adding behavior to an Abstract Class well into the future
without breaking your existing code –> this is not possible with an
Interface Class.

On the other hand, Interface Classes are more flexible than Abstract
Classes. This is because they can implement multiple interfaces. The
thing is Java does not have multiple inheritances so using abstract
classes won’t let you use any other class hierarchy structure…

So, in the end a good general rule of thumb is: Prefer using Interface
Classes when there are no existing/default implementations in your
codebase. And, use Abstract Classes to preserve compatibility if you
know you will be updating your class in the future.”

Good luck on your next interview!