implements & abstract classes

A class that promises a shape

A checkout page lets the shopper pay by card or with a gift card. Each way to pay is a class, and the checkout calls the same method on each one: pay. Here it is in plain JavaScript (Class basics covers classes). One class got its method name wrong:

class CardPayment {
  pay(amount) {
    return `Paid $${amount} by card`;
  }
}

class GiftCardPayment {
  charge(amount) {
    return `Paid $${amount} with a gift card`;
  }
}

const methods = [new CardPayment(), new GiftCardPayment()];
for (const method of methods) {
  console.log(method.pay(7));
}

Lines 1 to 5 make CardPayment, with a pay method. Lines 7 to 11 make GiftCardPayment, but its method on line 8 is called charge. Line 13 puts one of each in a list, and line 15 calls pay(7) on each. The card prints Paid $7 by card. The gift card has no pay, so the code stops with TypeError: method.pay is not a function. The first person to find out is a shopper with a gift card.

In TypeScript, you can write down the shape every payment method must have, and make each class promise to have it. The shape is an interface: a named list of the properties and methods an object must have (the Type aliases & interfaces lesson introduced them). The promise is the word implements:

1interface PaymentMethod {2  pay(amount: number): string;3}4 5class CardPayment implements PaymentMethod {6  pay(amount: number) {7    return `Paid $${amount} by card`;8  }9}10 11class GiftCardPayment implements PaymentMethod {12  charge(amount: number) {13    return `Paid $${amount} with a gift card`;14  }15}

Lines 1 to 3 are the interface. PaymentMethod says: anything that is a payment method has a pay method that takes a number and gives back a string. Line 5 says CardPayment implements PaymentMethod, and it does. Line 11 makes the same promise for GiftCardPayment, and TypeScript marks it, on purpose, because the class breaks its promise:

• Class 'GiftCardPayment' incorrectly implements interface 'PaymentMethod' means "this class said it has the shape of PaymentMethod, and it doesn't".
• The second line of the message says what's wrong: Property 'pay' is missing in type 'GiftCardPayment' but required in type 'PaymentMethod'.

Nobody has used the class yet, and the mistake is already marked, on the class itself. Try it: type a different name for the gift card's method and watch the list under the code.

1interface PaymentMethod {2  pay(amount: number): string;3}4 5class CardPayment implements PaymentMethod {6  pay(amount: number) {7    return `Paid $${amount} by card`;8  }9}10 11class GiftCardPayment implements PaymentMethod {12  charge(amount: number) {13    return `Paid $${amount} with a gift card`;14  }15}

With pay, the class keeps its promise and the error disappears. Pay with a capital P and payNow keep the error: the checkout calls pay, so only that exact name counts.

Interfaces are one way to share a shape. The second half of this lesson covers the other: an abstract class, a base class with real code and some blanks that every class built on it must fill in.

What implements checks, and what it doesn't

Without implements, TypeScript still catches the wrong method name, but later: only where the class is used as a PaymentMethod. Here the checkout function on lines 11 to 13 takes a PaymentMethod, and line 15 passes it a gift card. Press each button and watch where the errors appear:

1interface PaymentMethod {2  pay(amount: number): string;3}4 5class GiftCardPayment {6  charge(amount: number) {7    return `Paid $${amount} with a gift card`;8  }9}10 11function checkout(method: PaymentMethod, total: number) {12  console.log(method.pay(total));13}14 15checkout(new GiftCardPayment(), 7);

Without implements, only line 15 gets an error: Argument of type 'GiftCardPayment' is not assignable to parameter of type 'PaymentMethod'. An argument is a value you pass in a call. The message is right, but it points at the place the class is used, not the place the mistake is. With implements, line 5 gets its own error, right on the class. Both errors go when line 6 says pay.

A class can promise more than one shape. List the interfaces after implements, with commas:

1interface PaymentMethod {2  pay(amount: number): string;3}4 5interface Refundable {6  refund(amount: number): string;7}8 9class CardPayment implements PaymentMethod, Refundable {10  lastFour = "4242";11  pay(amount: number) {12    return `Paid $${amount} by card`;13  }14  refund(amount: number) {15    return `Refunded $${amount} to the card`;16  }17}18 19const card = new CardPayment();20console.log(card.pay(7));21console.log(card.refund(3), card.lastFour);

• Lines 1 to 3 and 5 to 7 are two interfaces: one for paying, one for giving money back.
• Line 9 promises both. TypeScript checks for pay (lines 11 to 13) and refund (lines 14 to 16).
• Line 10 adds lastFour, which neither interface asks for. That's fine: a class may have more than its interfaces list.
• Line 20 prints Paid $7 by card, and line 21 prints Refunded $3 to the card 4242.

Now the part that surprises most people. implements is only a check. It doesn't change the class in any way, so it doesn't type the class's methods for you:

1interface PaymentMethod {2  pay(amount: number): string;3}4 5class CashPayment implements PaymentMethod {6  pay(amount) {7    return `Pay $${amount.toFixed(2)} at the door`;8  }9}10 11console.log(new CashPayment().pay(7));

The interface says pay takes a number, so you might expect amount on line 6 to be a number too. It isn't. TypeScript types the class first, on its own, and only then compares it with the interface. Line 6 gets Parameter 'amount' implicitly has an 'any' type: amount has no type, so TypeScript uses any, which means "anything, and don't check it", and strict mode won't do that silently. Point at amount to see (parameter) amount: any. Line 11 still prints Pay $7.00 at the door. Write pay(amount: number) and the error goes.

For the same reason, an optional property in the interface doesn't appear on the class:

1interface Profile {2  name: string;3  avatarUrl?: string;4}5 6class GuestProfile implements Profile {7  name = "Guest";8}9 10const guest = new GuestProfile();11guest.avatarUrl = "/images/guest.png";

Line 3 says a Profile may have an avatarUrl; the ? makes it optional. Lines 6 to 8 make a guest profile with only a name, and that keeps the promise. Line 11 sets guest.avatarUrl, and TypeScript says Property 'avatarUrl' does not exist on type 'GuestProfile'. The class is exactly what you wrote in it. To have an avatar, declare avatarUrl?: string; in the class.

The table sums it up. Read each row as: something you might expect from implements, does it do it, and why.

Abstract classes: a base with a blank to fill in

A shop has discount codes. Every discount works the same way: work out how much to take off, then take it off the total. Only the first step differs: one code takes 10% off, another takes $5 off. In JavaScript, you'd write the shared part once in a parent class and let child classes build on it with extends (Class inheritance covers extends). TypeScript lets you mark the parent class abstract and leave the different part blank:

1abstract class Discount {2  constructor(public code: string) {}3 4  abstract amountOff(total: number): number;5 6  apply(total: number) {7    return total - this.amountOff(total);8  }9}10 11class PercentOff extends Discount {12  amountOff(total: number) {13    return total * 0.1;14  }15}16 17const spring = new PercentOff("SPRING10");18console.log(spring.code, spring.apply(20));

• Line 1 makes Discount an abstract class. It's meant to be built on, not used on its own.
• Line 2 stores the discount's code, like "SPRING10", with a parameter property.
• Line 4 is an abstract method: a name, its parameters, and its return type, with no body. It says "every discount has an amountOff that takes a total and gives back a number, and each subclass writes its own".
• Lines 6 to 8 are a normal method that every discount shares. apply calls this.amountOff(total) without knowing which discount it is.
• Line 11 makes PercentOff, a subclass of Discount: a class that builds on it. Lines 12 to 14 fill in the blank: take off 10% of the total.
• Line 17 makes a PercentOff. Line 18 prints SPRING10 18: the code, then 20 minus 2.

What you can't do is make a Discount itself. It has a blank, so there would be nothing to call:

1abstract class Discount {2  constructor(public code: string) {}3 4  abstract amountOff(total: number): number;5 6  apply(total: number) {7    return total - this.amountOff(total);8  }9}10 11const mystery = new Discount("MYSTERY");12console.log(mystery.apply(20));

Line 11 tries new Discount("MYSTERY"), and TypeScript says Cannot create an instance of an abstract class. An instance is an object made from a class with new. When the code runs anyway, line 12 calls apply, which calls this.amountOff, which doesn't exist: TypeError: this.amountOff is not a function.

The rules for abstract members

A class that extends an abstract class must write every abstract member, unless it's abstract too. Try four ways of writing amountOff in a HalfOff discount:

1abstract class Discount {2  constructor(public code: string) {}3 4  abstract amountOff(total: number): number;5 6  apply(total: number) {7    return total - this.amountOff(total);8  }9}10 11class HalfOff extends Discount {12  amountOff(total: number) { return total / 2; }13}14 15const half = new HalfOff("HALF");16console.log(half.apply(20));

Left out gets Non-abstract class 'HalfOff' does not implement inherited abstract member amountOff from class 'Discount'. A non-abstract class is one you can make objects from, so it can't have blanks. Returns text breaks the abstract method's promise to give back a number. No parameter is fine: a method may ignore values it's given, so it can take fewer parameters than the abstract method lists.

Two more rules, each broken here on purpose:

1class Banner {2  abstract render(): string;3}4 5abstract class Popup {6  abstract render(): string {7    return "Sale!";8  }9}

• Line 1 makes Banner without abstract, and line 2 gives it an abstract method. TypeScript says Abstract methods can only appear within an abstract class: a class you can make objects from can't have a blank.
• Line 6 gives an abstract method a body. TypeScript says Method 'render' cannot have an implementation because it is marked abstract. An implementation is the code inside the braces. For a method with code that subclasses may replace, leave out abstract.

A property can be abstract too. The base class uses it, and each subclass gives it a value:

1abstract class Notice {2  abstract title: string;3 4  show() {5    return `[${this.title}]`;6  }7}8 9class SaleNotice extends Notice {10  title = "Summer sale";11}12 13console.log(new SaleNotice().show());

Line 2 says every Notice has a title that is a string, without giving one. Lines 4 to 6 use it in show. Line 10 gives SaleNotice its title, and line 13 prints [Summer sale]. Leave out line 10 in Edit & run and line 9 gets the same "does not implement inherited abstract member" error.

Interfaces or abstract classes?

Both describe a shape that classes must match. The big difference is what's left when the types are removed. Here is an interface and an abstract class together:

1interface PaymentMethod {2  pay(amount: number): string;3}4 5abstract class Payment implements PaymentMethod {6  abstract pay(amount: number): string;7 8  receipt(amount: number) {9    return `Receipt: ${this.pay(amount)}`;10  }11}

Lines 1 to 3 are the interface. Line 5 makes an abstract class that promises to keep it. An abstract class can leave an interface's method blank, as line 6 does with pay; its subclasses will write it. Lines 8 to 10 are real code that every payment shares: a receipt. Here is what TypeScript gives the browser:

class Payment {
  receipt(amount) {
    return `Receipt: ${this.pay(amount)}`;
  }
}

The interface is gone. So are implements, the word abstract, and the abstract method on line 6: they were only types. Line 1 is a normal JavaScript class, and lines 2 to 4 are the receipt method, word for word.

Because the abstract class is still there when the code runs, you can test for it with instanceof, which asks "was this object made by this class, or a subclass of it?" (Checking types covers instanceof). You can't test for an interface:

1interface PaymentMethod {2  pay(amount: number): string;3}4 5abstract class Payment implements PaymentMethod {6  abstract pay(amount: number): string;7}8 9class CardPayment extends Payment {10  pay(amount: number) {11    return `Paid $${amount} by card`;12  }13}14 15const card = new CardPayment();16console.log(card instanceof Payment);17console.log(card instanceof PaymentMethod);

Line 16 prints true: the card was made by CardPayment, a subclass of Payment. Line 17 gets 'PaymentMethod' only refers to a type, but is being used as a value here. In plain words: that name is only a type, and instanceof needs something that exists while the code runs. If you run it anyway, line 17 stops with ReferenceError: PaymentMethod is not defined.

The table compares the two. Read each row as a question, then the answer for an interface and for an abstract class.

A simple way to choose:

• Use an interface to say what something can do, when the classes or objects that match it share no code. Many unrelated classes, and plain objects, can match it.
• Use an abstract class when the classes share real code, like apply or receipt, and each must fill in its own part.
• Use both, as above: the interface for the shape the rest of your code uses, and the abstract class for the shared code.

Payment methods on a checkout page

Here is a checkout that uses both. The rest of the page only knows about PaymentMethod. An abstract class shares the code that works out a total with a fee, and a voucher is a plain object:

1interface PaymentMethod {2  label: string;3  pay(amount: number): string;4}5 6abstract class Payment implements PaymentMethod {7  abstract label: string;8  abstract fee(amount: number): number;9 10  pay(amount: number) {11    const total = amount + this.fee(amount);12    return `${this.label}: $${total}`;13  }14}15 16class CardPayment extends Payment {17  label = "Card";18  fee() {19    return 0;20  }21}22 23class CashOnDelivery extends Payment {24  label = "Cash on delivery";25  fee(amount: number) {26    return amount < 20 ? 2 : 0;27  }28}29 30const voucher: PaymentMethod = {31  label: "Voucher",32  pay: (amount) => `Voucher: $${amount} covered`,33};34 35const methods: PaymentMethod[] = [new CardPayment(), new CashOnDelivery(), voucher];36for (const method of methods) {37  console.log(method.pay(12));38}

• Lines 1 to 4 are the interface: every payment method has a label to show on the page and a pay method.
• Lines 6 to 14 are the abstract class. Lines 7 and 8 are blanks: each payment has its own label and its own fee. Lines 10 to 13 add the fee to the amount and build the text the page shows.
• Lines 16 to 21 fill in the blanks for cards: no fee. Lines 23 to 28 do it for cash on delivery: $2 for orders under $20.
• Lines 30 to 33 make a voucher as a plain object, with no class at all. The : PaymentMethod on line 30 is enough: TypeScript checks the object against the interface, and it even gives amount on line 32 its type, because the object is written right where a PaymentMethod is expected.
• Line 35 puts all three in one list of PaymentMethod. Line 37 prints Card: $12, Cash on delivery: $14, and Voucher: $12 covered.

Now sort each card. Will TypeScript report an error, or is it fine?

Common mix-ups

• "implements adds the interface's methods to my class." No. An interface has no code to add. You write every member, and implements checks them.
• "implements gives my method's parameters their types." No. The class is typed on its own first. Write pay(amount: number), or amount is any.
• "I can check instanceof PaymentMethod." No. An interface is removed with the types, so there's nothing to check against while the code runs. Use an abstract class, or check for the method.
• "An abstract class can't have any code." No. It can have fields, a constructor, and normal methods like apply. Only its abstract members are blank.
• "abstract stops the class from being made while the page runs." No. The word is removed with the types. It's TypeScript that reports new Discount(), before the code runs.
• "A class can extend two abstract classes." No. It can extend one class, and implement as many interfaces as it likes.

Practice exercises

Each exercise is TypeScript. Press Edit & run on the starter code: the errors update as you type, and the console shows what it prints. Try a guess first, then use the hints.

interface Theme {
  name: string;
  apply(): string;
}

class DarkTheme implements Theme {
  name = "dark";
}

1interface Theme {2  name: string;3  apply(): string;4}5 6class DarkTheme implements Theme {7  name = "dark";8  apply() {9    return `Theme set to ${this.name}`;10  }11}12 13console.log(new DarkTheme().apply());

1abstract class Greeting {2  abstract name(): string;3 4  text() {5    return `Hello, ${this.name()}!`;6  }7}8 9class GuestGreeting extends Greeting {10  name() {11    return "guest";12  }13}14 15console.log(new GuestGreeting().text());

1abstract class Greeting {2  abstract name(): string;3 4  text() {5    return `Hello, ${this.name()}!`;6  }7}8 9class GuestGreeting extends Greeting {10  name() {11    return "guest";12  }13}14 15// text() comes from Greeting, and it calls GuestGreeting's name().16console.log(new GuestGreeting().text());

1abstract class Discount {2  constructor(public code: string) {}3 4  abstract amountOff(total: number): number;5 6  apply(total: number) {7    return total - this.amountOff(total);8  }9}10 11class FreeShipping extends Discount {}12 13const shipping = new FreeShipping("FREESHIP");14console.log(shipping.code, shipping.apply(20));

1abstract class Discount {2  constructor(public code: string) {}3 4  abstract amountOff(total: number): number;5 6  apply(total: number) {7    return total - this.amountOff(total);8  }9}10 11class FreeShipping extends Discount {12  amountOff() {13    return 5;14  }15}16 17const shipping = new FreeShipping("FREESHIP");18console.log(shipping.code, shipping.apply(20));

1interface SearchBox {2  query: string;3  clear(): void;4}5 6class HeaderSearch implements SearchBox {7  query = "green tea";8  reset() {9    this.query = "";10  }11}12 13const box = new HeaderSearch();14box.clear();15console.log(`[${box.query}]`);

1interface SearchBox {2  query: string;3  clear(): void;4}5 6class HeaderSearch implements SearchBox {7  query = "green tea";8  clear() {9    this.query = "";10  }11}12 13const box = new HeaderSearch();14box.clear();15console.log(`[${box.query}]`);

1interface PriceFormatter {2  format(price: number): string;3}4 5class DollarFormatter implements PriceFormatter {6  format(price) {7    return `$${price.toFixed(2)}`;8  }9}10 11console.log(new DollarFormatter().format(4.5));

1interface PriceFormatter {2  format(price: number): string;3}4 5class DollarFormatter implements PriceFormatter {6  format(price: number) {7    return `$${price.toFixed(2)}`;8  }9}10 11console.log(new DollarFormatter().format(4.5));

1class SavedToast {2  message() {3    return "Saved";4  }5  show() {6    return `Toast: ${this.message()}`;7  }8}9 10class ErrorToast {11  message() {12    return "Could not save";13  }14  show() {15    return `Toast: ${this.message()}`;16  }17}18 19console.log(new SavedToast().show());20console.log(new ErrorToast().show());

1abstract class Toast {2  abstract message(): string;3 4  show() {5    return `Toast: ${this.message()}`;6  }7}8 9class SavedToast extends Toast {10  message() {11    return "Saved";12  }13}14 15class ErrorToast extends Toast {16  message() {17    return "Could not save";18  }19}20 21console.log(new SavedToast().show());22console.log(new ErrorToast().show());

Check your understanding

For each question, think about two moments: what TypeScript says before the code runs, and what the code does when it runs. The quiz shows its code without the checker, so the error list doesn't give the answers away.

Key takeaways

• class CardPayment implements PaymentMethod promises the class has the interface's shape, and TypeScript marks the class line if it doesn't.
• A class can implement several interfaces, and may have more members than they list.
• implements only checks. It doesn't add members, type parameters, or leave anything in the JavaScript.
• An abstract class shares real code and leaves abstract members blank. You can't make one with new, and every non-abstract subclass must fill in every blank.
• An interface disappears from the JavaScript; an abstract class stays as a normal class, so instanceof works with it.

Coming next: Static members & class types. It shows what a class name means as a type, the type of the class itself, and members that belong to the class instead of its objects.