Name the inheritance shape before tracing it

Classify single, multilevel, hierarchical and diamond inheritance before comparing Java and Python rules. Inheritance and polymorphism · Object-oriented programming.

A payment app has a CardPayment and a WalletPayment, both built on one Payment, and a RefundableCardPayment that wants to build on both. If both parents offer a refund(), which one runs? The answer depends on the language, so first name the shape the parent edges draw.

One edge is single inheritance. A row of edges, each class with one parent, is a chain, called multilevel inheritance. Sibling classes that share one parent are hierarchical inheritance. Two branches that meet again below a shared ancestor form a diamond: the joining type has two parents, and both lead back to the same ancestor. Two parents alone do not make a diamond, because a class whose parents never meet at a shared ancestor is multiple inheritance but not a diamond. The word names the picture; it does not promise one object layout or one lookup result.

Java: one superclass, several interface contracts

Java 17 and later give each class at most one direct superclass; Object is the root class with none. A class may also implement several interfaces, and an interface may extend several interfaces. That lets Java draw a diamond among Root, Left, Right and Join as a type and contract graph without implying two superclass objects.

The extends edges between interfaces describe inherited contracts. The implements edges from Join describe capabilities that the class promises. Base is the one direct class superclass in the fixed example, and it declares no f() method.

Here is a complete Java/Python pair. The Java side makes the default-method boundary explicit: Left.f() and Right.f() are unrelated defaults, while Join.f() supplies the resolving declaration. The Python side uses the same names to show a valid multiple-inheritance declaration, while keeping its lookup rule separate.

interface Root { }
interface Left extends Root {
    default String f() { return "left"; }
}
interface Right extends Root {
    default String f() { return "right"; }
}
class Base { }
final class Join extends Base implements Left, Right {
    @Override public String f() { return Left.super.f(); }
}

class Root:
    def f(self):
        return "Root"

class Left(Root):
    def f(self):
        return "Left>" + super().f()

class Right(Root):
    def f(self):
        return "Right>" + super().f()

class Join(Left, Right):
    def f(self):
        return "Join>" + super().f()

Without the override, class Join implements Left, Right { } does not compile: javac reports that Join inherits unrelated defaults for f(). The override can still reuse one parent: inside Join.f(), Left.super.f() calls Left’s default, and Right.super.f() calls Right’s. Java never picks the first interface listed.

The conflict needs two unrelated defaults. If interface Sub extends Left overrides f(), then in class J2 implements Left, Sub the more specific Sub.f() wins and nothing conflicts. If the superclass Base has a concrete f(), that method wins over both defaults.

Python: the order is part of the contract

Python 3 permits class Join(Left, Right) when the hierarchy admits a consistent C3 method resolution order. For this fixed declaration order, the visible search order is Join, Left, Right, Root, object. Python builds that list by three rules. A class comes before its parents. Bases keep the order written in the class statement, so Left comes before Right. A shared ancestor comes only after every class that inherits from it, so Root waits until both Left and Right are placed. That is why lookup does not go depth-first to Root after Left.

The list is an ordered lookup rule, not a diagram of five stored object bodies. If an attribute is absent on Join, lookup checks the next class in that order. Some base orders have no consistent list. If B inherits from A, then class X(A, B) raises TypeError when the class is created, because A would have to come both before and after B. Writing class X(B, A) works.

Each body forwards with super().f(), so the fixed receiver Join() produces "Join>Left>Right>Root" along the displayed MRO. Notice that Left calls super().f() and lands in Right, a sibling it does not inherit from. super() continues after the current class in the MRO; it does not mean “call the textual parent next to this class,” and here the next class in Join’s MRO is Right, not Root. Root runs once, after both branches.

Practical rule: prefer small interfaces or composition to deep multiple inheritance. When you do use a Python diamond, make every class call super().f() with the same signature so each class runs once.

Recap

• Single, multilevel, hierarchical and diamond shapes describe different parent-edge patterns.
• Two parents alone do not make a diamond, and Java is not free of the problem: two interface defaults can conflict.
• Java has one superclass but many interfaces; two unrelated defaults with the same signature must be resolved by the class, optionally with Left.super.f().
• Python’s consistent C3 MRO makes lookup order explicit, and super() follows that order.

You have completed the Inheritance and polymorphism module; continue to object relationships to move from what a class inherits to which objects hold links to, share or own one another. Practise reading parent edges and paths in Graph Fundamentals.