Abstract Classes vs Interfaces

An abstract class — a half-built parent

An abstract class is a normal class with one twist: you can't create an object from it directly — it's unfinished. But it can carry almost everything a real class carries, and it hands all of it down to its children:

• Stored data (fields) — like a battery level — that every child inherits automatically.
• A constructor — setup code that runs when a child object is built.
• Fully-written methods — real code, like charge(), that every child gets for free.
• Blank abstract methods — a method name with no body, which each child is forced to fill in.

A child extends the base and is a kind of it. The one big limit: a class can extend only one base — just as a real product sits on a single chassis. That single inheritance is what keeps the shared-data story simple.

// Can't do `new Device()` — it's half-built on purpose.
abstract class Device {
  protected battery = 0;            // stored data — every child inherits it

  charge(pct: number): void {      // real, working code — children get it free
    this.battery = Math.min(100, this.battery + pct);
  }

  abstract turnOn(): string;       // blank — each child MUST fill this in
}

An interface — a checklist of an ability

An interface is leaner: classically it's just method names, no bodies and no stored data. A class implements it by writing the real code for every method it lists. The superpower is that a single class can implement many interfaces at once — stacking abilities that come from completely unrelated places.

// Interface = the promise of an ability. No data, no code — just the list.
interface Recordable { record(): string; }
interface Connectable { connectWifi(): void; }

// One class can wear MANY stickers at once:
class SmartCamera extends Device implements Recordable, Connectable {
  turnOn()      { return "camera live"; }   // fills Device's blank
  record()      { return "recording 4K…"; } // fulfils Recordable
  connectWifi() { /* … */ }                 // fulfils Connectable
}

Most real classes use both

These aren't rivals — the everyday answer is to use them together. Extend one abstract base for the shared data and code, and implement several interfaces for the extra abilities. SmartCamera is a Device (so it gets battery and charge() for free) and can do Recordable and Connectable (so it promises those abilities and writes them itself). Base for what they are; interfaces for what they can do.

A simple way to choose

Start with an interface — it's the lighter, more flexible choice, and types that share nothing but an ability can still take it on. Reach for an abstract class the moment you want to share real code or stored data across children that genuinely form an is-a family (a SmartCamera and a SmartBulb really are both a kind of Device). And when both pulls are real at once, don't pick — use an abstract base for the shared part and layer interfaces on top for the extra abilities. That last combo is what most real designs land on.