In TypeScript, when would you model a contract as an abstract class rather than as an interface, and what does each choice cost?

## The question behind the question Interviewers ask this to see whether you reason about the *type layer versus the runtime*, or just recite a list. In TypeScript the honest framing is: an interface is a pure type-space declaration; an abstract class is a real JavaScript class that additionally refuses `new`. Everything else follows from that. ## What only an abstract class can do **Ship implementation.** Method bodies in the base are inherited by every subclass. This is the whole point of the template-method shape: ```ts abstract class Job { async run(): Promise<void> { const start = Date.now(); await this.execute(); console.log(`${this.name} took ${Date.now() - start}ms`); } protected abstract name: string; protected abstract execute(): Promise<void>; } ``` The timing and logging exist once. With an interface, every implementer writes them again. **Hold state and construction logic.** Fields, initialization, argument validation in the constructor — all run for every subclass instance through `super(...)`. An interface has no constructor and no storage. **Declare non-public members.** `protected abstract execute()` above is a hook visible to subclasses and invisible to callers. An interface cannot express that at all: interface members are public by definition, so the moment you put `execute` in an interface you have published it. **Exist as a value.** The class binding survives compilation, so it can be exported, referenced, stored in a registry, or used where a runtime class object is required. An interface name cannot be used in any value position. ## What only an interface can do **Cost nothing.** It emits no code. Nothing is added to the bundle, and there is no prototype link at runtime. **Be satisfied many times over.** A class has exactly one `extends` slot, and taking it is a permanent decision for the implementer; a class can satisfy any number of interfaces. If your contract is one of several a type might need, an abstract class is an expensive way to express it. **Be satisfied structurally, without a declaration.** TypeScript's type relationships are structural: an object literal or a class from a library you do not control can match an interface without ever naming it. Nothing can "accidentally" be a subclass of your abstract class — inheritance has to be written down. **Be reopened.** Interface declarations with the same name in the same scope merge, which is what makes ambient augmentation of third-party types possible. A class declaration cannot be extended after the fact this way. ## The costs, stated honestly Choosing an abstract class costs the implementer their single inheritance slot and binds them to your base class's future: add a member, and every subclass in every consumer is affected; change a protected hook's signature, and they all must follow. Choosing an interface costs you duplication — if there is real shared logic, each implementer writes it, and they will drift. That is the trade in one sentence: **an abstract class centralises code at the price of coupling; an interface avoids coupling at the price of duplication.** The broader design debate about inheritance versus composition is language-agnostic and lives with object-oriented design theory; what matters for a TypeScript answer is which mechanism actually expresses your intent in this type system. ## They are not exclusive The usual mature answer combines them: ```ts interface Notifier { send(message: string): Promise<void>; } abstract class RetryingNotifier implements Notifier { async send(message: string): Promise<void> { for (let attempt = 0; attempt < 3; attempt++) { try { await this.deliver(message); return; } catch { // retry } } throw new Error('delivery failed after 3 attempts'); } protected abstract deliver(message: string): Promise<void>; } ``` Consumers depend on `Notifier` — the erased shape, satisfiable by anything, mockable with an object literal in tests. Implementers may extend `RetryingNotifier` to inherit the retry loop, or may not. You get centralised behaviour without forcing it on anyone, and the published contract stays a shape. ## Practical decision rules - Contract crossing a module or package boundary, or a type consumers must satisfy: **interface**. - Genuine shared algorithm with named holes, used by a closed set of implementers you own: **abstract class**. - Need for `protected` members in the contract: **abstract class**, because interfaces cannot express visibility. - Need the contract to be satisfiable by types you do not control: **interface**, because structural matching does not require a declaration. - Anything you want to mock trivially in tests: an interface is easier — a plain object literal satisfies it, with no base constructor to run. ## The failure mode to avoid The common mistake is an abstract class with no implemented members at all — every member abstract, no fields, no constructor. That is an interface written with extra ceremony: it emits a class into the bundle, burns the implementer's `extends` slot, and buys nothing. If the base has nothing to give, make it an interface.