Interface vs abstract class interview questions, with answers

The questions, with answers

1. 1.What is the difference between an interface and an abstract class?

   An abstract class is a class: it can hold instance fields, define constructors, have methods with any access level, and a subclass extends exactly one of them. An interface is a contract: it has no instance state and no constructors, its methods are implicitly public, and a class can implement as many as it likes. Both can contain abstract methods, and since Java 8 both can contain implemented ones — default and static methods in interfaces — so "interfaces have no code" is no longer the difference.

   The one-sentence version interviewers accept: an abstract class shares implementation and state down a single hierarchy; an interface declares a capability that unrelated classes can each promise to provide.

2. 2.When should you choose an abstract class over an interface?

   Choose an abstract class when the subclasses share state or a partial implementation that belongs in one place — a base Shape that stores a colour and implements describe() once, leaving area() abstract. It is also the right home for a template method: a public method whose steps are fixed but whose individual steps are abstract hooks. Choose an interface when the trait cuts across otherwise unrelated types — Comparable, Runnable, Closeable — or when a class already extends something and needs a second contract. If you are unsure, start with an interface: it commits you to less, and an abstract class can implement it later without breaking callers.

3. 3.Can an interface have method implementations?

   Yes, in modern Java. Since Java 8 an interface can declare default methods, which have a body and are inherited by implementing classes unless overridden, and static methods, which belong to the interface itself. Java 9 added private methods so defaults can share helper code. C# 8 added default interface methods too. What an interface still cannot have is instance fields — any field declared in a Java interface is implicitly public static final, a constant — and it cannot have a constructor. So a default method can only work with the interface's other methods, never with per-object state, which is precisely the boundary that keeps it an interface.

   interface Greeter {
       String name();                                   // abstract
       default String greet() { return "Hello, " + name(); }   // implemented, overridable
       static Greeter of(String n) { return () -> n; }  // belongs to the interface
   }

4. 4.What is the point of a constructor in an abstract class, if it can never be instantiated?

   It can have a constructor, and usually should — that is how it initialises the fields it owns — but it cannot be instantiated directly: new Shape() is a compile error when Shape is abstract. The constructor runs when a concrete subclass is created, because the subclass constructor calls super(...) first, explicitly or implicitly. The nuance interviewers like: you can write new Shape() { ... } with a body, but that creates an anonymous concrete subclass, not an instance of the abstract class. And an abstract class with no abstract methods at all is legal; marking it abstract is a way of saying "only meaningful as a base".

5. 5.What happens when a class implements two interfaces that define the same default method?

   The class must resolve the conflict itself or it will not compile — Java reports that the class inherits unrelated defaults for the method. The fix is to override the method in the class and, if one of the inherited bodies is what you want, call it explicitly with InterfaceName.super.method(). If the two interfaces declare the same abstract method with no body, there is no conflict: the class implements it once and satisfies both. Java's rule of thumb is that class wins over interface, and a more specific sub-interface wins over its parent, so a conflict only arises between two unrelated interfaces at the same level.

   interface A { default String hi() { return "A"; } }
   interface B { default String hi() { return "B"; } }
   
   class C implements A, B {
       @Override public String hi() { return A.super.hi() + B.super.hi(); }   // must resolve
   }

6. 6.How does Java avoid the diamond problem while still allowing multiple interfaces?

   The diamond problem is about state and construction: if two parents both inherit a field from a common grandparent, which copy does the grandchild get, and which constructor initialises it? Java sidesteps it by allowing only one superclass, so there is one chain of constructors and one copy of every field. Interfaces carry no instance fields and no constructors, so implementing several of them cannot produce two copies of anything — the worst that can happen is two default methods with the same signature, and that is a compile-time conflict you resolve by overriding. C++ allows true multiple inheritance and handles the diamond with virtual inheritance instead, which is the comparison worth offering if the interviewer works in C++.

7. 7.What are marker interfaces and functional interfaces?

   A marker interface has no methods at all; implementing it tags the class so that code can check it with instanceof. Serializable and Cloneable are the classic examples: the JVM checks Serializable before writing an object, and Object.clone() throws unless the class is Cloneable. Annotations largely replaced the pattern for new code. A functional interface has exactly one abstract method — Runnable, Comparator, Callable — which is what lets a lambda expression stand in for an implementation. The @FunctionalInterface annotation is optional, but it makes the compiler reject a second abstract method, so the interface cannot silently stop being lambda-compatible.

8. 8.Can an abstract class implement an interface without implementing all of its methods?

   Yes. An abstract class may leave any number of the interface's methods unimplemented; they remain abstract, and the first concrete subclass has to supply them. That is a common design: AbstractList in the JDK implements List, provides most of the methods in terms of get() and size(), and leaves those two to subclasses. A concrete class, by contrast, must implement every abstract method it inherits from anywhere — its own abstract superclass and every interface — or it does not compile. The rule is simple: abstractness can be postponed down the hierarchy, but it cannot survive a non-abstract class.

How the diagnostic asks it

One question from the OOP bank, exactly as a sitting would show it. The bank has 4 on interfaces vs abstract classes and 60 across OOP.