Abstraction

Your order service sends an SMS when an order is confirmed. So it knows the vendor’s API key, the sender id, the DLT template id, and the retry rule. Then the company switches SMS vendors to save 3 paise a message, and the pull request touches checkout, refunds, login and the delivery tracker. Four teams review a change that was supposed to be about SMS.

Checkout never needed to know any of that. It needed one thing: tell this customer their order is confirmed.

The idea

An abstraction is a small, stable description of what something does, with the how left out. In TypeScript the tool for it is the interface.

Before: the caller knows everything

function placeOrder(phone: string, orderId: number): string {
  // ...the order is saved, then:
  const apiKey = 'key_live_8f2a'
  const senderId = 'INDGEK'
  const templateId = '1107160000012345'
  const auth = `key=${apiKey} from=${senderId} template=${templateId}`
  const body = `Order ${orderId} confirmed`
 
  return `POST sms.example/send ${auth} to=${phone} text=${body}`
}
 
console.log(placeOrder('9810012345', 42).length > 100) // true

Four of the six lines in that function have nothing to do with placing an order. And they are copied into every other function that sends a message.

After: the caller knows one method

interface Notifier {
  send(to: string, message: string): string
}
 
class SmsNotifier implements Notifier {
  private readonly senderId = 'INDGEK'
 
  send(to: string, message: string): string {
    return `SMS from ${this.senderId} to ${to}: ${message}`
  }
}
 
class WhatsAppNotifier implements Notifier {
  send(to: string, message: string): string {
    return `WhatsApp to ${to}: ${message}`
  }
}
 
function placeOrder(
  notifier: Notifier,
  phone: string,
  orderId: number,
): string {
  // ...the order is saved, then:
  return notifier.send(phone, `Order ${orderId} confirmed`)
}
 
console.log(placeOrder(new SmsNotifier(), '9810012345', 42))
// > SMS from INDGEK to 9810012345: Order 42 confirmed
console.log(placeOrder(new WhatsAppNotifier(), '9810012345', 42))
// > WhatsApp to 9810012345: Order 42 confirmed

placeOrder now takes a Notifier. That type has one method on it, so one method is all placeOrder can see, even though SmsNotifier has a sender id and could have twenty more details. implements Notifier asks the compiler to confirm the class really has everything the interface lists.

Switching vendors is now a new class and one line where it is created. Checkout is not in the pull request.

TypeScript checks the shape, not the name

This is where TypeScript differs from Java and C#, and it is worth ten minutes of your attention.

interface Notifier {
  send(to: string, message: string): string
}
 
class PushNotifier {
  send(to: string, message: string): string {
    return `Push to ${to}: ${message}`
  }
}
 
const notifier: Notifier = new PushNotifier()
console.log(notifier.send('asha', 'Your rider is here'))
// > Push to asha: Your rider is here
 
const fake: Notifier = { send: (to, message) => `(test) ${to}: ${message}` }
console.log(fake.send('asha', 'hello')) // (test) asha: hello

PushNotifier never says implements Notifier, and it is accepted anyway. So is a plain object with a send function. TypeScript asks one question: does this value have the methods the interface lists, with compatible types? This is called structural typing.

So why write implements at all? Because it moves the error. Without it, a typo in PushNotifier shows up far away, at the line where you try to use it as a Notifier. With it, the compiler complains inside the class, where the mistake is.

The plain object version is how you write a test double in three lines. That comes back in Dependency inversion.

When the implementations share code: abstract class

An interface has no code in it. If every notifier needs the same prefix and only the delivery differs, you would be pasting the prefix into each class. An abstract class is a half finished class: some methods are written, some are left as blanks to fill in.

abstract class Notifier {
  // Written once, shared by every notifier.
  send(to: string, message: string): string {
    return this.deliver(to, `[IndGeek] ${message}`)
  }
 
  // A blank. Each subclass must fill it in.
  protected abstract deliver(to: string, text: string): string
}
 
class SmsNotifier extends Notifier {
  protected override deliver(to: string, text: string): string {
    return `SMS to ${to}: ${text}`
  }
}
 
const notifier = new SmsNotifier()
console.log(notifier.send('9810012345', 'Order 42 confirmed'))
// > SMS to 9810012345: [IndGeek] Order 42 confirmed
 
const blank = new Notifier()
// Error: Cannot create an instance of an abstract class.

You cannot new an abstract class, because it has holes in it. protected means subclasses can see deliver and outside callers cannot. extends and override get a full page next, in Inheritance.

Two ways to get it wrong

Checkpoint