Why Some Languages Ban Multiple Inheritance

Because a class carries state, and two parents can both contribute members with the same name. When that happens, the language has to decide which one the subclass gets, and any answer is either arbitrary or needs a rule the programmer has to learn. The diamond problem is the classic shape of this trouble: a class inherits from two paths that meet at a common ancestor, and the shared ancestor's members arrive twice.

public class Main {
    public static void main(String[] args) {
        Printable p = new LaserPrinter();
        System.out.println(p.describe());
        System.out.println(p.source());
    }
}

interface Printable {
    default String source() { return "printable"; }
    default String describe() { return "uses " + source(); }
}

interface Duplexable {
    default String source() { return "duplexable"; }
}

class LaserPrinter implements Printable, Duplexable {
    public String source() { return Printable.super.source(); }
}

The example shows the conflict in miniature. Both interfaces supply a default source method, so a class implementing both would have two candidates for it. Java refuses to choose silently. The class has to say which one it wants, and the qualified form Printable.super.source() is the explicit syntax for that. If it had not said, the code would not compile.

The output shows the resolved behaviour: the printer reports that it uses printable, and asking for the source directly gives the same answer. The class had to resolve the conflict itself, and the qualified call names the winner explicitly.

The design principle behind the restriction is that ambiguity should be a compile error rather than a runtime surprise. Java handles this by separating the two kinds of inheritance. State comes from one class parent, so there is never a question about which inherited field you get. Behaviour can come from several interfaces, and when two of them supply the same default method the compiler forces you to resolve it explicitly.

Through interfaces. A class may implement any number of them, so behaviour can be assembled from several independent contracts, each with a single clear responsibility. Where the contracts overlap, an interface can extend another interface, which is how you build a richer contract out of a simpler one.

public class Main {
    public static void main(String[] args) {
        Megaphone m = new Loud();
        m.shout("hello");
        m.speak();
    }
}

interface Speaker {
    void speak();
}

interface Megaphone extends Speaker {
    default void shout(String text) { System.out.println(text.toUpperCase()); }
}

class Loud implements Megaphone {
    public void speak() { System.out.println("speaking"); }
}

The example shows both mechanisms at once. The megaphone interface extends the speaker interface, so anything that can shout can also speak, and the shout method comes with a default implementation. The loud class then implements the whole thing and supplies the one abstract method, speak. The output confirms the combination works: the inherited default prints HELLO and the implemented method prints speaking.

Where an interface cannot help, composition is the answer. Hold the extra behaviour as a collaborator and delegate to it. That gives you the same ability to combine capabilities, with the difference that the collaborators stay independent and can each be replaced, tested or reused on their own.

The comparison to remember for an interview: class inheritance is for an is-a relationship with shared state and shared behaviour, while interfaces and composition are for mixing in capabilities. Java supports the first strictly and the second liberally, and that combination is why most real Java hierarchies stay shallow.

The diamond problem is what happens when a class inherits from two branches that converge on a common ancestor, and that ancestor contributes a member. The subclass sees the ancestor twice, once through each path. For behaviour, the language has to pick one or complain. For state, it is worse, because copying the ancestor's fields twice produces two copies that can drift apart, so a change made through one path is not visible through the other.

Java's answer is to keep state inheritance single and let behaviour come from interfaces. Interfaces carry no instance state, so inheriting the same default method through two paths is resolvable. Where two interfaces genuinely collide, the compiler refuses to guess and the implementing class must name the one it wants, which turns a silent ambiguity into an explicit decision.

Other languages take different routes. Some support multiple inheritance of classes and define a linearisation order that determines which method wins, which is well defined but requires the programmer to understand the ordering rules. Some use mixins, where a method set is composed into a class rather than inherited from a parent. Some use traits, which allow the inheriting class to override the mixed-in behaviour as if it had written it itself.

The deeper point is that the ambiguity is not really about syntax, it is about ownership. When two sources both claim to provide a member, somebody has to say which source is authoritative, and every language that allows multiple inheritance has to invent a mechanism for that answer. The cleanest designs avoid the question by keeping one source of state and many sources of behaviour, and by preferring composition when the relationship is not genuinely an is-a.