Interfaces Across Languages

The big difference is nominal versus structural typing. Java and C# are nominally typed for interfaces: a class must say it implements an interface, and the compiler checks the methods. Go is structural for interfaces: a type satisfies an interface automatically if it has the right methods, with no declaration at all. Python is dynamic, so an object satisfies any interface it happens to have the methods for, checked at run time.

public class Main {
    public static void main(String[] args) {
        Notifier n = new ConsoleNotifier();
        System.out.println(n.notify("hello"));
        ConsoleLogger l = new ConsoleLogger();
        l.log("hello");
        System.out.println("duck typing works at run time");
    }
}

interface Notifier {
    String notify(String message);
}

class ConsoleNotifier implements Notifier {
    public String notify(String message) { return "notified: " + message; }
}

class ConsoleLogger {
    void log(String message) { System.out.println("logged: " + message); }
}

The example shows the Java behaviour and the alternative side by side. The notifier is explicitly declared as implementing the interface, so the compiler guarantees the contract. The console logger never mentions any interface, yet it has the same shape as one that does, and its method can be called directly. The last line makes the point that duck typing works at run time in languages that allow it.

The design consequences differ. In Java, the interface is a real type you can name in a signature, and the compiler is what enforces the relationship. In Go, the interface is usually defined by the consumer, which is why Go code tends to have small interfaces owned by the package that uses them. In Python, the relationship is invisible to the tooling, so explicit base classes or protocols are often used to bring the checking back.

The interview point is that the language choice shapes where you put the contract. Nominal languages let you define an abstraction once and share it; structural languages let each consumer define the tiny interface it needs, and the contract stays local to the code that uses it.

The biggest consequence is that a type is not related to another type unless you say so. A class that happens to have the right methods does not satisfy an interface, and the compiler will reject it. This means you can change an interface, or add a method to it, and the compiler will find every class that depended on it, which is a genuine benefit for large codebases.

The cost is verbosity and rigidity. Every implementation has to declare what it implements, and a class that wants to satisfy two unrelated contracts has to list both. More importantly, the direction of the dependency is fixed by whoever declares the interface, which means the interface tends to accumulate methods for all its users rather than for one particular caller.

It also makes small interfaces valuable. Because a class must opt in, you can offer a narrow contract that only the classes that genuinely support it implement, and clients can depend on that narrow contract. You cannot get the same effect through duck typing in a statically checked language.

The design advice that follows is worth stating: in a nominally typed language, spend the effort on getting the interface right early, because changing it is a breaking change for every implementor and every caller. Small, focused interfaces owned by the consumer are usually the best compromise, since they limit how much a single change can break.