Object-oriented programming (OOP) is hard to achieve in a dynamic prototypical language like JavaScript. You have to manually stick to OOP principles because of language features like duck typing. This requires discipline, as nothing in the language enforces the principles. If a diverse team of developers with different backgrounds is involved, a codebase filled with good intentions can quickly become one chaotic mess.

In this take, we will delve into proper OOP techniques in TypeScript, showing how the language automates a bunch of manual labor and encourages best practices. We will begin by talking a bit about duck typing, then go into the three pillars: encapsulation, inheritance, and polymorphism.

Ready? Let’s go!

A Bit of Duck Typing in TypeScript

You may follow along by copy-pasting code in the TypeScript Playground. The goal is for you to reproduce the following, to prove these techniques work in any codebase.

Take a look at the following:

interface Todo {
  title: string;
  description?: string;
}
 
const todo1 = {
  title: "organize desk",
  extra: "metadata", // duck typing is allowed!
};
 
const updateTodo = (
  todo: Todo,
  fieldsToUpdate: Partial<Todo> // allow partial updates
) => ({ ...todo, ...fieldsToUpdate });
 
const result1 = updateTodo(todo1, {
  description: "throw out trash",
});
 
const todo2 = {
  ...todo1,
  description: "clean up", // call bombs without description
};
 
const updateRequiredTodo = (
  todo: Required<Todo>,
  fieldsToUpdate: Partial<Todo>
): Required<Todo> => ({ ...todo, ...fieldsToUpdate });
 
const result2 = updateRequiredTodo(todo2, {
  description: "throw out trash",
});

The Todo interface is declared with an optional property description, so this code can skip the property. The question mark ? tells TypeScript that this is optional. One way to revert this design decision is to wrap the interface around Required<Todo>, which makes all properties non-optional. In classic OOP, the data integrity of objects matters. Here, the compiler automates this behavior.

If the intent is to allow partial updates, Partial<Todo> can revert to optional properties. This only affects the parameter fieldsToUpdate. The updateRequiredTodo function explicitly declares an output type of Required<Todo>, guaranteeing the object's shape when it returns.

Note that the property extra is accepted in todo1. This is a legacy from the fact that TypeScript is a superset of JavaScript, and duck typing is allowed. Without explicit typing, TypeScript has no choice but to revert to legacy. As you write more TypeScript programs, it is a good idea to lean on the type checker as much as possible via explicit types.

Now, let's look at object-oriented programming's three pillars.

The Three Pillars of Object-Oriented Programming with TypeScript

Encapsulation

This pillar is all about restricting access and decoupling software modules. TypeScript makes this information hiding technique achievable via a class.

class Base {
  private hiddenA = 0;
  #hiddenB = 0;
 
  printInternals() {
    console.log(this.hiddenA); // works
    console.log(this.#hiddenB); // works
  }
}
 
const obj = new Base();
console.log(obj.hiddenA); // these two bomb
console.log(obj.#hiddenB);

Here, the hiddenA member has restricted access within Base enforced by the compiler. However, the compiler gives JavaScript runtime constructs like in access to the hidden property. You can use the hard private # to maintain private fields.

A class isn’t the only tool available in your TypeScript arsenal. Utility types like Pick<Type, Keys>, Omit<Type, Keys>, Readonly<Type>, and NonNullable<Type> can also limit access.

interface Todo {
  title: string;
  description?: string; // string | undefined
  completed: boolean;
}
 
type TodoPreview1 = Pick<Todo, "title" | "completed">;
 
const todo1: TodoPreview1 = {
  //explicit typing
  title: "Clean room",
  completed: false,
  description: "x", // duck typing is NOT allowed
};
 
type TodoPreview2 = Omit<Todo, "description" | "completed">;
 
const todo2: TodoPreview2 = {
  title: "Clean room",
};
 
const todo3: Readonly<Todo> = {
  title: "Delete inactive users",
  completed: true,
};
 
todo3.completed = false; // bombs
 
const todo4: Todo = {
  ...todo1,
  description: "Doing shores is fun",
};
 
const description: NonNullable<string | undefined> =
  // bombs without null coalescing
  todo4.description ?? "";

The Pick and Omit utility types pluck a subset of properties. If an object is explicitly typed, then duck typing is not allowed. This technique slices and dices types and narrows the information available to the compiler.

Immutability is achievable via Readonly. Any attempt to mutate the object automatically fails the build. If you need protection at runtime, Object.freeze is also available. By limiting the objects that can mutate state, you enforce encapsulation, safeguarding interactions between types.

This whole time you may have assumed undefined or null is a natural consequence of working with OOP because nullable types are allowed. Well, offering nullable objects is like selling street mangos, then telling people you never intended to carry any!

A null is the absence of an object and is therefore diametrically opposed to object orientation. NonNullable helps you be honest about types so there are no unforeseen mishaps. Note that the compiler will bark at you if null doesn't coalesce, as description is no longer optional.

Inheritance

Inheritance represents a hierarchy of types with an is-a relationship. This technique can mirror real-world relationships. Say there's a Pingable interface with a ping method. For a Sonar to be Pingable it must implement this behavior. This makes reasoning about a Sonar easier because it models specific functionality.

interface Pingable {
  ping(): void;
}
 
class Sonar implements Pingable {
  ping() {
    console.log("sonar ping!");
  }
}

TypeScript also comes with fancier ways of achieving inheritance. Given two types, say Colorful and Circle, you can combine set properties in interesting ways via union and intersection.

With union types, narrowing is necessary via a type predicate. The circle is Circle predicate narrows the type so the logic can branch accordingly. The compiler needs this narrowing technique because it doesn’t know which type to pick from the disjunction.

type Colorful = {
  color: string;
};
 
type Circle = {
  radius: number;
};
 
type ColorfulCircle = Colorful | Circle; // union
 
function isCircle(circle: ColorfulCircle): circle is Circle {
  return "radius" in circle;
}
 
function draw(circle: ColorfulCircle) {
  if (isCircle(circle)) {
    // branch logic
    console.log(`Radius was ${circle.radius}`); // ok
  } else {
    console.log(`Color was ${circle.color}`);
  }
}
 
draw({ color: "blue" });
draw({ radius: 42 });

Below, Colorful and Circle intersect to create a new type with properties from both. This promotes code reuse, much like classic inheritance.

type Colorful = {
  color: string;
};
 
type Circle = {
  radius: number;
};
 
type ColorfulCircle = Colorful & Circle; // intersection
 
function draw(circle: ColorfulCircle) {
  console.log(`Radius was ${circle.radius}`); // ok
  console.log(`Color was ${circle.color}`);
}
 
draw({ color: "blue", radius: 42 });

The this object in JavaScript can be a mess to work with because it changes depending on the context. TypeScript types this dynamically to the class and has type guards.

abstract class Box {
  content: string = "";
 
  sameAs(other: this) {
    return other.content === this.content;
  }
 
  isDerivedBox(): this is DerivedBox {
    return this instanceof DerivedBox;
  }
}
 
class DerivedBox extends Box {
  otherContent: string = "?";
}
 
const base = new Box(); // bombs
const derived = new DerivedBox();
derived.isDerivedBox(); // true
derived.sameAs(derived as Box); // bombs

Note that the this is DerivedBox type guards the return type in the isDerivedBox method. Mixing this with type narrowing via instanceof makes this a predictable type instead of a moving target.

This technique creates concrete OOP types with reasonable behavior where the consuming code can ignore implementation details. The Box class is also abstract, and the compiler restricts access by not allowing instances of the class. Contracts with common behavior decouple from concrete objects that may want to reuse some of the rich functionality.

Polymorphism in Object-Oriented Programming

You can achieve ad hoc polymorphism by using arguments that behave differently depending on the type. Let's look at an add method that works generically and changes behavior accordingly.

interface GenericAdd<AddType> {
  add: (x: AddType, y: AddType) => AddType;
}
 
class GenericNumber implements GenericAdd<number> {
  add(x: number, y: number) {
    return x + y;
  } // number + number
}
 
class GenericString implements GenericAdd<string> {
  add(x: string, y: string) {
    return x + y;
  } // string + string
}
 
const genericNumber = new GenericNumber();
genericNumber.add(1, 2); // 3
 
const genericString = new GenericString();
genericString.add("Hello", ", Mammals!"); // Hello, Mammals!

If you think of a type as a record, it is possible to have row-polymorphic records, with code that operates only on a section of a type. TypeScript makes this easy via Partial. Note that subset is explicitly typed, and duck typing is not allowed since beta is not a subset of AType.

type AType = { x: number; y: number; z: number };
 
const subset: Partial<AType> = {
  x: 2,
  y: 3,
  beta: "bomb", // not allowed
};

For the pièce de résistance, apply the Liskov Substitution principle with composition and the Decorator Pattern. At runtime, the object gains functionality via polymorphic behavior.

Say there's a Barista class that wants to make different kinds of coffee. The relationship here is that a barista has-a cup of coffee, which in OOP parlance means composition versus inheritance. Like a cup of coffee, the object being prepared can have milk, sugar, or sprinkles added. My barista is busy and doesn’t have time for convoluted wretched code, so everything must be reusable and easy to use.

interface Coffee {
  getCost(): number;
  getIngredients(): string;
}
 
class SimpleCoffee implements Coffee {
  getCost() {
    return 8;
  }
 
  getIngredients() {
    return "Coffee";
  }
}
 
abstract class CoffeeDecorator implements Coffee {
  constructor(private readonly decoratedCoffee: Coffee) {}
 
  getCost() {
    return this.decoratedCoffee.getCost();
  }
 
  getIngredients() {
    return this.decoratedCoffee.getIngredients();
  }
}
 
class WithMilk extends CoffeeDecorator {
  constructor(private readonly c: Coffee) {
    super(c);
  }
 
  getCost() {
    return super.getCost() + 2.5;
  }
 
  getIngredients() {
    return super.getIngredients() + ", Milk";
  }
}
 
class WithSprinkles extends CoffeeDecorator {
  constructor(private readonly c: Coffee) {
    super(c);
  }
 
  getCost() {
    return super.getCost() + 1.7;
  }
 
  getIngredients() {
    return super.getIngredients() + ", Sprinkles";
  }
}
 
class WithSugar extends CoffeeDecorator {
  constructor(private readonly c: Coffee) {
    super(c);
  }
 
  getCost() {
    return super.getCost() + 1;
  }
 
  getIngredients() {
    return super.getIngredients() + ", Sugar";
  }
}

The Coffee interface works like a contract used consistently throughout the code and models a real-world object. For example, a cup of coffee has some ingredients and costs money. The starting price is $8, assuming US currency and adjusting for inflation, set in SimpleCoffee.

The decorator pattern is a good example of the Liskov substitution principle because all subtypes of the CoffeeDecorator stick to this same contract. This makes the code more predictable and intuitive. Because TypeScript does a good job of ensuring subclasses implement contracts, it is harder for developers to sneak odd behavior in weird places.

class Barista {
  constructor(private readonly cupOfCoffee: Coffee) {}
 
  orders() {
    this.orderUp(this.cupOfCoffee);
    let cup: Coffee = new WithMilk(this.cupOfCoffee);
    this.orderUp(cup);
    cup = new WithSugar(cup);
    this.orderUp(cup);
    cup = new WithSprinkles(cup);
    this.orderUp(cup);
  }
 
  private orderUp(c: Coffee) {
    console.log(
      "Cost: " + c.getCost() + "; Ingredients: " + c.getIngredients()
    );
  }
}
 
const barista = new Barista(new SimpleCoffee());
barista.orders();

As shown, the consuming code remains easy to use and nukes a lot of complexity. This is the ultimate goal in OOP: to abstract away all your problems. So my barista doesn’t waste time poring through low-level code to make a simple cup of coffee.

As a bonus, this code is now testable because the Barista class sticks to the same contract. You can inject a mock that implements Coffee to unit test all of this code.

Wrap Up: Use Proper Object-Oriented Programming Techniques in TypeScript

In this post, I've run through the three pillars of object-oriented programming — encapsulation, inheritance, and polymorphism — and have also introduced duck typing.

You've seen how TypeScript automates best practices, thus, you no longer need to rely on sheer willpower or discipline. This helps you stick to OOP principles, as well as get rid of code smells. Your types and the compiler should become allies to keep your code clean and free from unfortunate accidents.

Happy coding!

P.S. If you liked this post, subscribe to our JavaScript Sorcery list for a monthly deep dive into more magical JavaScript tips and tricks.

P.P.S. If you need an APM for your Node.js app, go and check out the AppSignal APM for Node.js.