What Is an Interface?

An interface is a named contract. It lists the operations a type promises to support without providing an implementation of them, so it describes what a collaborator can do and nothing about how. A class that implements it is bound by that promise, and the compiler checks the promise at build time.

public class Main {
    public static void main(String[] args) {
        Greeter g = new FormalGreeter();
        System.out.println(g.greet("Ada"));
        Greeter h = new CasualGreeter();
        System.out.println(h.greet("Grace"));
    }
}

interface Greeter {
    String greet(String name);
}

class FormalGreeter implements Greeter {
    public String greet(String name) { return "Good day, " + name; }
}

class CasualGreeter implements Greeter {
    public String greet(String name) { return "Hey " + name; }
}

The example shows the guarantee in action. Both greeters satisfy the same contract, and the caller holds a Greeter reference in both cases. The output differs, and the caller has no way to tell from the code which implementation it received, nor does it need to. That is the point of the contract: the call site is written once and works for every implementation.

Because the interface is the shared vocabulary, the caller's knowledge is bounded. When a new greeting style appears, you add a class and the caller is untouched. If instead the caller had depended on the concrete classes, adding one would have meant editing every place that used them.

What the interface does not give you is a guarantee about implementation. It says nothing about thread safety, about performance, or about whether two implementations behave identically in edge cases. Those are the guarantees you have to document or design for separately, and knowing the difference between a promised contract and an accidental behaviour is what separates a careful answer from a recited one.

An abstract class can carry state and implemented behaviour, and a class can extend only one of them. An interface carries a contract and, since default methods were added, some shared behaviour, but it holds no instance state, and a class can implement as many interfaces as it likes.

The practical differences follow from that. An abstract class is the right choice when the subclasses genuinely share code and state, such as a common base that holds a protected field and a template method. An interface is the right choice when you want to express a capability that unrelated classes might have, such as being serialisable or comparable.

There is also the visibility question. A class member in an abstract class can be protected or package-private, so subclasses can work with inherited internals. An interface's members are public, so implementing it exposes them to everyone. That makes an abstract class better when the shared state should stay inside the hierarchy, and an interface better when the contract is a public promise.

A class can do both: extend one abstract class and implement several interfaces. When you are unsure, prefer the interface, because it is the more flexible choice and easier to refactor away from later.

The main benefit is that the interface becomes the unit of dependency. Callers depend on it, so they can be written, tested and reasoned about without knowing the implementation, and the implementation can be replaced without touching them. It is also the mechanism that makes a seam for testing possible, since a fake can be supplied for the interface.

The second benefit is that it makes the set of valid implementations explicit. Writing the contract first forces you to describe the capability in terms of what callers need, which is often the moment you discover that the real requirement is two smaller capabilities rather than one.

The costs are real too. Every interface adds a file, an indirection and a thing to keep in sync. The contract becomes a promise that is expensive to change, because every implementation has to change with it. And a badly designed interface can be worse than no interface at all, because a fat contract forces unrelated classes to carry methods they have no use for.

The judgement to state in an interview is about how many implementations and how much change you expect. If you can name a second implementation or need a test double, the interface is paying for itself. If not, it is a speculative layer that adds cost without buying flexibility, and a plain class is the honest choice.