Interface or abstract class: which boundary fits?

Choose an interface for a capability contract or an abstract class for shared family state, setup and behavior. Inheritance and polymorphism · Object-oriented programming.

A receipt service must send the same receipt through a screen or through a locker, and another part of the program must send reports that all start by writing the same audit label. Java gives two tools for these two needs: an interface, which lists what a type can do, and an abstract class, which is an unfinished parent that supplies shared state and setup. Watch what the client must know, then what the family must share.

Start with the capability

Imagine a receipt service that can deliver through a screen or a locker. The client only needs the deliver capability. The two channels are not one natural family, and the client should not depend on either concrete class.

The ReceiptChannel interface is a contract. A variable typed as that interface can refer to either implementation that declares implements ReceiptChannel. Changing the object changes the delivery detail while the client-facing operation stays stable. The interface boundary does not require the implementations to share a superclass or instance fields.

interface ReceiptChannel {
    String deliver(String receipt);
}

final class ScreenChannel implements ReceiptChannel {
    public String deliver(String receipt) { return "screen: " + receipt; }
}

final class LockerChannel implements ReceiptChannel {
    public String deliver(String receipt) { return "locker: " + receipt; }
}

ReceiptChannel channel = new ScreenChannel();
channel.deliver("R-18");

from abc import ABC, abstractmethod

class ReceiptChannel(ABC):
    @abstractmethod
    def deliver(self, receipt):
        pass

class ScreenChannel(ReceiptChannel):
    def deliver(self, receipt):
        print("screen:", receipt)

channel = ScreenChannel()
channel.deliver("R-18")

One class can promise more than one capability: class ScreenChannel implements ReceiptChannel, Archivable. Each interface is a separate view of the same object; call the set of methods a variable's declared type offers that variable's port. A variable typed ReceiptChannel has a port that shows only deliver, so channel.archive("R-18") does not compile even though the object has archive; assign the same object to an Archivable variable to reach it.

interface Archivable { String archive(String receipt); }

final class ScreenChannel implements ReceiptChannel, Archivable {
    public String deliver(String receipt) { return "screen: " + receipt; }
    public String archive(String receipt) { return "archived"; }
}

ScreenChannel s = new ScreenChannel();
ReceiptChannel c = s;
Archivable ar = s;
c.deliver("R-18");
ar.archive("R-18");

The Python tab is a qualified comparison: ABC and @abstractmethod express a Python abstract base class, not a Java interface. Python ABCs can also hold concrete methods and instance setup. At run time Python refuses to create an object from an ABC, or from a subclass that has not implemented every @abstractmethod, and raises TypeError. Python also has typing.Protocol, a structural contract: any class with a matching deliver method satisfies it, with no implements or base class, and normally only a type checker enforces it (isinstance works only if the Protocol is marked @runtime_checkable, and then it only checks that the method exists). Neither is a Java interface.

The method kinds have different jobs

An interface can share a small behavior without becoming a stateful base class. The method kind tells you what the implementing object can receive.

A Java interface method with no body and no default, static or private modifier is implicitly public and abstract. A default method has a body and is inherited as instance behavior when an implementation does not override it. A static method is called through the interface name, such as ReceiptChannel.label(), and is not inherited by implementing objects. A private method is a helper for the interface’s own method bodies; it is neither inherited nor overridden.

interface ReceiptChannel {
    int MAX_LENGTH = 40;
    String deliver(String receipt);
    default String preview(String r) { return "preview: " + trim(r); }
    private String trim(String r) { return r.length() > MAX_LENGTH ? r.substring(0, MAX_LENGTH) : r; }
    static String label() { return "receipt"; }
}

With ScreenChannel channel, channel.preview("R-18") works, but channel.label() does not compile; write ReceiptChannel.label().

The interface may declare fields, but each is implicitly public static final and must be initialized. That is a constant shared by the type, not a separate field on every channel. Constructors belong to classes. A class implementing the interface can have its own fields and constructors.

The compact distinction matters: default shares behavior, while an abstract class can share behavior and per-object state. If two unrelated interfaces contribute conflicting defaults, Java requires an override to resolve the conflict; the later inheritance diamond lesson walks through the full conflict path.

A family with shared setup

Now consider two report channels from one family. Every channel records the same audit label and uses the same audit operation, but each concrete channel supplies its own send operation. That is a natural place for an abstract class.

AuditedChannel cannot be constructed directly because it is abstract; new AuditedChannel("x") fails to compile even though the class has a constructor, because that constructor exists only to be run by a subclass. When ScreenReport is constructed, its abstract superclass constructor runs first and initializes the inherited auditLabel field. The concrete subclass then supplies send. This is shared family setup, not a promise that every unrelated type belongs in the same hierarchy.

abstract class AuditedChannel {
    protected final String auditLabel;

    protected AuditedChannel(String auditLabel) {
        this.auditLabel = auditLabel;
    }

    protected String audit(String receipt) {
        return auditLabel + ": " + receipt;
    }

    abstract String send(String receipt);
}

final class ScreenReport extends AuditedChannel {
    ScreenReport() { super("screen"); }
    String send(String receipt) { return audit(receipt); }
}

from abc import ABC, abstractmethod

class AuditedChannel(ABC):
    def __init__(self, audit_label):
        self.audit_label = audit_label

    def audit(self, receipt):
        print(self.audit_label, receipt)

    @abstractmethod
    def send(self, receipt):
        pass

class ScreenReport(AuditedChannel):
    def __init__(self):
        super().__init__("screen")

    def send(self, receipt):
        self.audit(receipt)

The Java and Python examples share a teaching shape, not a feature-by-feature promise. Python’s ABC machinery decides whether the abstract method is satisfied; Java’s abstract class and constructor rules are the Java claims shown here.

Ask two questions before choosing. Can a type satisfy the operation without inheriting the same data and setup? That points toward an interface. Must every member of one family receive the same invariant state and preparation? That points toward an abstract class. A default method can support a small shared behavior, but it does not answer the second question because it cannot add interface instance state or a constructor.

Recap

• An interface names a capability that different implementations can provide, and a class can provide several; each variable sees only its own interface's methods.
• Java default shares instance behavior; static and private methods stay qualified to the interface or its own bodies.
• An abstract class is a partial family implementation when state, constructor setup or concrete behavior belongs to every subclass.

Continue to method dispatch to trace what a later call does with the boundary you chose. Practise choosing a small operation contract through enqueue and dequeue in Queue Fundamentals.