Implementing Multiple Interfaces

A class can implement any number of interfaces, and each one it lists is a separate promise it has to keep. The compiler checks all of them, so if a class declares an interface but does not supply its abstract methods, the code does not compile.

public class Main {
    public static void main(String[] args) {
        Employee e = new Employee();
        System.out.println(e.work());
        System.out.println(e.report());
    }
}

interface Worker {
    String work();
}

interface Reporter {
    String report();
}

class Employee implements Worker, Reporter {
    public String work() { return "working"; }
    public String report() { return "reporting"; }
}

The example is the easy case, where the interfaces do not overlap. The employee satisfies both contracts, and the output shows both behaviours being available. The class can be passed to code that expects a Worker, to code that expects a Reporter, or to code that expects both.

The interesting case is overlap. Two interfaces can both supply a default method with the same signature, and if a class implements both, the compiler reports that the inherited method is ambiguous. The class has to resolve it, either by overriding the method itself or by naming one of the parents explicitly with the qualified super form.

That requirement is deliberate. It means the class author, who is the person who knows all the contexts the class will be used in, decides which behaviour applies, rather than the compiler applying an ordering rule that nobody remembers.

You resolve it inside the class that implements both. There are two forms. The first is to override the method in the class and write the behaviour you want, possibly delegating to one of the interface versions. The second is the qualified super call, which names the parent whose version you want and lets you add to it.

public class Main {
    public static void main(String[] args) {
        Printer p = new BasicPrinter();
        System.out.println(p.print("hi"));
    }
}

interface Printer {
    default String print(String text) { return "plain: " + text; }
}

interface ColourPrinter {
    default String print(String text) { return "colour: " + text; }
}

class BasicPrinter implements Printer, ColourPrinter {
    public String print(String text) { return Printer.super.print(text); }
}

The example uses the qualified form, and the output shows the plain behaviour winning. If the class had preferred the colour version, the qualified name would have referred to the other interface and the output would have changed. The point is that the choice is explicit and visible in the class.

If you do nothing, the code does not compile. The compiler reports that the inherited method is ambiguous and has to be overridden. That is a deliberate design decision, because the alternative, picking one arbitrarily, would make the behaviour of the class depend on a rule the reader would have to know.

One related note for an interview: the conflict is only a problem for default methods, because abstract methods with the same signature are simply the same requirement and one implementation satisfies both. So two interfaces can share an abstract method without any friction.

Start by questioning whether every interface belongs in the list. A class that implements six interfaces is usually telling you that it has too many unrelated responsibilities, and the better fix is to split the class rather than to tidy the interface list. A class that can genuinely do six things at once is rare.

Second, keep the interfaces narrow. If an interface has methods that are only meaningful together, keep them together. If a method is used by only one caller of the interface, it probably belongs on that caller or on a separate interface, and pulling it out lets the class implement only what applies to it.

Third, do not let the interface become a place to collect things you want to call from somewhere. A method added to a shared interface because one distant caller needed it makes every implementor carry a method they have no use for, and the next addition is worse.

Fourth, watch the inheritance of interfaces with default methods. A class that implements several interfaces inherits all their default methods, so it can acquire behaviour it never asked for. When two of those defaults collide, the class is forced to resolve it, which is a signal that the interface hierarchy has become tangled.

The interview summary is that multiple interfaces give flexibility, and the price is that every list has to stay short and every contract has to stay narrow. The discipline is to add an interface when a capability genuinely appears, not when a method is needed somewhere.