Abstract Classes vs Interfaces

What an abstract class can carry

An abstract class sits halfway between a normal class and a pure contract. It cannot be instantiated on its own, but it can hold almost everything a regular class can:

• Fields / instance state — it can store data, like a name or a cached value, that every subclass inherits.
• A constructor — it can run setup code when a subclass object is built (subclasses call super(...)).
• Concrete methods — fully written methods that all subclasses get for free, plus abstract methods that subclasses are forced to fill in.

The catch: in most languages a class can extend exactly one abstract class. You inherit a single base, so it's the right home for a shared identity plus shared machinery.

What an interface can carry

An interface is a leaner thing — a contract of method signatures with (classically) no bodies and no stored state. A class implements an interface by providing real code for every method it names. The superpower is multiplicity: a single class can implement many interfaces at once, mixing capabilities from completely unrelated contracts.

// Interface: just the capability, no state, no constructor.
interface Drawable {
  draw(): void; // a signature — the WHAT, no HOW
}

// One class can promise MANY unrelated capabilities at once:
class Widget implements Drawable, Serializable, Clickable {
  draw() { /* ... */ }
  serialize() { /* ... */ }
  onClick() { /* ... */ }
}

Modern languages blurred the line a little: since Java 8, interfaces can carry default methods (a shared body) and static methods — yet they still hold no instance state. TypeScript interfaces describe object shapes and are purely structural (they vanish at runtime). Python uses abc.ABC for abstract base classes and Protocol for interface-style structural typing. C++ has no separate interface keyword at all — an interface there is just an abstract class whose methods are all pure virtual (= 0).

The decision rule

When both seem to fit, ask two questions. Is there shared code or state every subtype should inherit, and is this an "is-a" relationship? → reach for an abstract class. Do unrelated types just need to advertise the same ability, with each writing its own version? → reach for an interface. And when you need both — shared state and the freedom to mix several capabilities — the idiomatic answer is to combine them: an abstract base for the shared part, interfaces for each extra capability.

Picking between the two

Default to an interface — it's the looser, more composable choice, and types that share nothing but a capability can still implement it. Promote to an abstract class the moment you find yourself wanting to share real code or stored state across subtypes that genuinely form an "is-a" family. When both pulls are real at once, don't choose — use an abstract base for the shared part and layer interfaces on top for the mix-in capabilities.