Abstraction vs interface vs abstract class

Published 21 October 2026

These three get compared as if they were three options on the same menu. They are not. One of them is an idea, and the other two are ways of writing that idea down.

Abstraction is the idea: show the caller what something can do and hide how it does it. The switch on the wall from the abstraction chapter is an abstraction. You press it and the light comes on, whether the power is from the grid, the inverter or the solar panel on the roof.

An interface and an abstract class are two TypeScript tools for building that switch. Think of a restaurant chain. The menu card is an interface: it lists what every outlet must be able to serve, and says nothing about recipes. The franchise kitchen manual is an abstract class: steps one to three are written out and every outlet follows them exactly, and step four says "your local special goes here".

Abstraction does not need either keyword#

Before the two tools, notice that you can have abstraction with neither of them. This type alias is an abstraction too. Checkout depends on "something that can send a message to a phone" and knows nothing about SMS vendors:

type Notify = (phone: string, text: string) => string
 
function placeOrder(notify: Notify) {
  return notify('9810012345', 'Order 42 confirmed')
}
 
const sms: Notify = (phone, text) => `SMS to ${phone}: ${text}`
console.log(placeOrder(sms)) // SMS to 9810012345: Order 42 confirmed

So the useful question is never "abstraction or interface?". It is "I want an abstraction here. Which tool do I write it with?" A function type for one operation, an interface for a set of operations, an abstract class when the implementations share real code.

Interface: the what, and nothing else#

An interface is a list of members a thing must have. It has no code in it, no fields with values, and no constructor.

interface PaymentGateway {
  charge(rupees: number): string
}
 
class Razorpay implements PaymentGateway {
  charge(rupees: number) {
    return `razorpay charged ${rupees}`
  }
}
 
class Paytm implements PaymentGateway {}
// Error: Class 'Paytm' incorrectly implements interface 'PaymentGateway'.
 
function checkout(gateway: PaymentGateway) {
  return gateway.charge(499)
}
 
console.log(checkout(new Razorpay())) // razorpay charged 499

implements asks the compiler to check the class against the contract, which is why the empty Paytm is rejected. There is something more surprising, and it matters every day in TypeScript: the check is about shape, not names. Anything with a charge(rupees) method that returns a string is a PaymentGateway, whether or not it says implements.

interface PaymentGateway {
  charge(rupees: number): string
}
 
function checkout(gateway: PaymentGateway) {
  return gateway.charge(499)
}
 
// No class and no implements. It has the right shape, so it fits.
const fakeGateway = { charge: (rupees: number) => `fake ${rupees}` }
 
console.log(checkout(fakeGateway)) // fake 499

That is called structural typing, and it is why interfaces make testing cheap in TypeScript: a test fake is a one line object. Java and C# do not work like this. There, a class only counts as an interface if it says so.

Abstract class: the what, plus part of the how#

An abstract class is a class you are not allowed to create directly. It can hold real methods, fields and a constructor, and it can mark some methods abstract, meaning "every child must write this one".

abstract class Gateway {
  charge(rupees: number): string {
    if (rupees <= 0) throw new Error('bad amount')
    return this.send(rupees)
  }
  protected abstract send(rupees: number): string
}
 
class Razorpay extends Gateway {
  protected send(rupees: number) {
    return `razorpay charged ${rupees}`
  }
}
 
console.log(new Razorpay().charge(499)) // razorpay charged 499
 
const g = new Gateway()
// Error: Cannot create an instance of an abstract class

The amount check now lives in one place. Each gateway only writes send, the one step that is actually different. The parent decides the order of the steps, and the child fills a hole. (That shape has its own name, the template method pattern, which comes up again in strategy vs template method vs command.)

What is left after it compiles#

This is the difference people forget, and the one that explains most of the others. TypeScript's types are checked and then thrown away: the browser and Node run plain JavaScript. Switch between the two contracts and the two views below.

interface PaymentGateway {
  charge(rupees: number): string
}

class Razorpay implements PaymentGateway {
  charge(rupees: number) {
    if (rupees <= 0) throw new Error('bad amount')
    return `razorpay: ${rupees}`
  }
}

class Paytm implements PaymentGateway {
  charge(rupees: number) {
    if (rupees <= 0) throw new Error('bad amount')
    return `paytm: ${rupees}`
  }
}

An interface has no runtime existence at all. So you cannot import it into plain JavaScript, you cannot check x instanceof PaymentGateway, and it costs zero bytes in your bundle. An abstract class is a real class that ships, so instanceof works and its shared code runs. The abstract keyword itself is erased, though. Only TypeScript stops new Gateway().

interface PaymentGateway {
  charge(rupees: number): string
}
 
const x: unknown = { charge: () => 'ok' }
const ok = x instanceof PaymentGateway
// Error: 'PaymentGateway' only refers to a type, but is being used
// as a value here.

The differences that matter in practice#

The last row is the one teams find out about the hard way. Add refund() to a PaymentGateway interface with nine implementations and nine classes stop compiling. Add it to an abstract class with a sensible default and none of them do.

You can have both#

The answer most senior engineers give in practice: callers depend on the interface, and the abstract class is an optional helper for the people writing implementations.

interface PaymentGateway {
  charge(rupees: number): string
}
 
abstract class BaseGateway implements PaymentGateway {
  charge(rupees: number): string {
    if (rupees <= 0) throw new Error('bad amount')
    return this.send(rupees)
  }
  protected abstract send(rupees: number): string
}
 
class Razorpay extends BaseGateway {
  protected send(rupees: number) {
    return `razorpay ${rupees}`
  }
}
 
// A test fake skips the base class. It only needs the shape.
const fake: PaymentGateway = { charge: (r) => `fake ${r}` }
 
function checkout(gateway: PaymentGateway) {
  return gateway.charge(250)
}
 
console.log(checkout(new Razorpay())) // razorpay 250
console.log(checkout(fake)) // fake 250

Checkout never names BaseGateway. A new gateway can use the base class to get the amount check for free, or skip it, and a test can pass a one line object.

In the interview#

Checkpoint#