Abstract Classes & Access Modifiers

The plain-language idea

abstract class Shape {
  abstract area(): number;         // no body — subclasses must provide one
  describe(): string {
    return `Area: ${this.area()}`; // concrete method, shared by every subclass
  }
}

class Circle extends Shape {
  constructor(private radius: number) { super(); }
  area(): number { return Math.PI * this.radius ** 2; }
}

new Shape();   // ❌ cannot create an instance of an abstract class
new Circle(3); // ✅

abstract marks both the class itself (can't be new'd directly) and specific methods (no implementation, just a signature subclasses are required to fill in) — while describe(), a normal concrete method, is inherited and shared as-is. This is the prototype chain (from the JavaScript track) with the compiler enforcing a contract on top of it: every subclass genuinely has an area().

Access modifiers: TypeScript's compile-time privacy

class Account {
  private balance: number = 0;       // only accessible inside this class
  protected id: string = "acc_1";    // accessible in this class and subclasses
  public owner: string = "Ada";      // accessible from anywhere (the default)
}

abstract class Shape { abstract area(): number; } — no body here; it's a contract, not code.

BackNext

What people usually miss

Watch out

• private in TypeScript is erased at compile time — nothing stops plain JavaScript (or a type assertion) from reading account["balance"] at runtime; only #balance (real private fields) is enforced by the JS engine itself.
• private constructor() is a real, useful pattern for enforcing "only create instances of this class through a specific static factory method," a common building block for the singleton pattern.
• An abstract class can have a real constructor and concrete methods — it's not just an interface; it can share actual implemented behavior across subclasses, which a plain interface cannot.

Why this matters in interviews

"What's the difference between TypeScript's private and JavaScript's #private fields?" is a precise, current question — the honest answer (compile-time-only vs. runtime-enforced) shows you understand where TypeScript's guarantees actually stop.