Inheritance interview questions, with answers

The questions, with answers

1. 1.What is inheritance, and what problem does it solve?

   Inheritance lets a class (the subclass or derived class) acquire the fields and methods of another class (the superclass or base class), then extend or override them. It models an is-a relationship — a Car is a Vehicle — and its practical payoff is that code written against the base type works unchanged for every subtype, which is what makes runtime polymorphism possible. The test to state in an interview: if you can't honestly say "every X is a Y", don't inherit; use composition.

   class Vehicle {
       protected int wheels;
       void start() { System.out.println("Starting"); }
   }
   class Car extends Vehicle {
       Car() { wheels = 4; }
   }

2. 2.What are the types of inheritance, and which does Java support?

   Single (one base), multilevel (A → B → C), hierarchical (one base, several subclasses), multiple (one class with two or more bases) and hybrid (a mix). Java supports single, multilevel and hierarchical inheritance between classes, but not multiple inheritance of classes — a class extends exactly one class. It gets the useful part of multiple inheritance through interfaces, which a class may implement any number of. C++ supports all of them, including multiple inheritance of classes, which is where the diamond problem comes from.

3. 3.In what order do constructors and destructors run in an inheritance chain?

   Constructors run base-first: when you create a C that extends B that extends A, A's constructor completes, then B's, then C's — each class is initialised before the class that depends on it. In Java, the first statement of every constructor is a call to super(...); if you don't write one, the compiler inserts super() with no arguments, and if the base has no no-argument constructor that is a compile error. Destructors (C++) run in the reverse order, derived first, so an object is torn down from the outside in. Java has no destructors; finalize() is deprecated and should not be offered as the equivalent.

   class A { A() { System.out.println("A"); } }
   class B extends A { B() { System.out.println("B"); } }
   class C extends B { C() { System.out.println("C"); } }
   
   new C();   // prints A, B, C

4. 4.What are the rules for overriding a method in Java?

   Same name and same parameter list; a return type that is the same or a subtype of the original (covariant return); access that is the same or wider — an overriding method cannot be more restrictive, so public cannot become protected; and it may not declare broader checked exceptions. Static methods are not overridden but hidden, private methods are not visible to subclasses so cannot be overridden, and final methods cannot be overridden at all. Always write @Override: it turns a typo in the name or signature into a compile error instead of a silently unrelated method.

5. 5.What is the diamond problem?

   With multiple inheritance, if B and C both inherit from A and D inherits from both B and C, D contains two copies of A's members, and a call to an A method through D is ambiguous. C++ resolves it with virtual inheritance — class B : virtual public A — so that D holds a single shared A. Java avoids it by disallowing multiple class inheritance. The nearest thing Java has is two interfaces with the same default method: the compiler refuses to guess and makes the class override the method and pick, for example with InterfaceB.super.method().

6. 6.When should you use composition instead of inheritance?

   When the relationship is has-a rather than is-a, or when you want to reuse behaviour without inheriting an interface you don't mean to expose. A Car has an Engine; it isn't an Engine. Composition keeps the two classes independent — you can swap the engine, test it alone, and changes to Engine's internals don't ripple into Car the way changes to a base class ripple into every subclass (the fragile base class problem). The usual guidance, "favour composition over inheritance", means inheritance is for substitutability, not for saving typing.

7. 7.Are private members inherited?

   The precise answer: a subclass object contains the superclass's private fields — they exist in memory and the superclass's own methods use them — but the subclass cannot access them by name, so in Java's terminology they are not inherited. If the subclass needs them, it goes through protected or public accessors. Protected members are accessible to subclasses (and, in Java, to the whole package), which is why protected is the access level you see on fields meant to be used by subclasses.

8. 8.What are upcasting, downcasting and object slicing?

   Upcasting treats a subclass object as its base type — Vehicle v = new Car() — and is always safe and implicit, because a Car is a Vehicle. Downcasting goes the other way, Car c = (Car) v, and is only safe if the object really is a Car; in Java a wrong downcast throws ClassCastException, so guard it with instanceof (or the pattern form, if (v instanceof Car c)). Slicing is a C++ hazard that Java doesn't have: assigning a Derived object to a Base variable by value copies only the Base part and the Derived fields are lost. Use pointers or references in C++ to keep polymorphism.

   Vehicle v = new Car();          // upcast, implicit
   if (v instanceof Car c) {       // safe downcast (Java 16+)
       c.openBoot();
   }

How the diagnostic asks it

One question from the OOP bank, exactly as a sitting would show it. The bank has 4 on inheritance and 30 across OOP.