TypeScript & Design Patterns: A Practical Guide

Written by

learnmodernjavascript

in

In the ever-evolving world of software development, writing clean, maintainable, and scalable code is paramount. This is where design patterns come into play. Design patterns are reusable solutions to commonly occurring problems in software design. They provide a blueprint for structuring code, making it easier to understand, modify, and extend. When combined with the power of TypeScript, a superset of JavaScript that adds static typing, you can create robust and reliable applications. This tutorial will guide you through several essential design patterns, demonstrating how to implement them effectively in TypeScript, with practical examples and clear explanations.

Why Design Patterns Matter

Imagine building a house without a blueprint. The process would be chaotic, inefficient, and prone to errors. Similarly, writing software without a structured approach can lead to messy code, difficult-to-debug issues, and challenges when scaling up your project. Design patterns offer solutions to these problems by providing proven, tested methods for organizing your code. They help you:

  • Improve Code Readability: Design patterns provide a common vocabulary and structure, making it easier for other developers (and your future self) to understand the code.
  • Enhance Maintainability: By adhering to established patterns, you reduce the likelihood of introducing bugs during modifications and updates.
  • Increase Reusability: Design patterns promote the creation of reusable components that can be applied in different parts of your application or even across multiple projects.
  • Boost Scalability: Well-designed code, based on design patterns, is generally easier to scale as your application grows.

TypeScript enhances the benefits of design patterns by providing static typing, which helps catch errors during development, improves code completion, and makes refactoring safer. Let’s dive into some key design patterns and how to implement them using TypeScript.

The Singleton Pattern

The Singleton pattern ensures that a class has only one instance and provides a global point of access to that instance. This is useful when you need to control access to a shared resource, such as a database connection or a configuration object. Let’s see how to implement this in TypeScript.

Implementation

Here’s a TypeScript implementation of the Singleton pattern:

class DatabaseConnection {
  private static instance: DatabaseConnection | null = null;
  private connectionString: string;

  private constructor(connectionString: string) {
    this.connectionString = connectionString;
  }

  public static getInstance(connectionString: string): DatabaseConnection {
    if (!DatabaseConnection.instance) {
      DatabaseConnection.instance = new DatabaseConnection(connectionString);
    }
    return DatabaseConnection.instance;
  }

  public query(sql: string): void {
    console.log(`Executing query: ${sql} on ${this.connectionString}`);
  }
}

// Example Usage:
const db1 = DatabaseConnection.getInstance("db_url_1");
const db2 = DatabaseConnection.getInstance("db_url_2");

db1.query("SELECT * FROM users;"); // Executes on db_url_1
db2.query("SELECT * FROM products;"); // Also executes on db_url_1, NOT db_url_2

console.log(db1 === db2); // true (Singleton ensures only one instance)

Explanation:

  • Private Constructor: The constructor is private, preventing direct instantiation of the `DatabaseConnection` class using the `new` keyword.
  • Static Instance: A static property `instance` holds the single instance of the class. It’s initialized to `null`.
  • `getInstance()` Method: This static method is the global access point. It checks if an instance already exists. If not, it creates one. If it does, it returns the existing instance.

Common Mistakes and Fixes

A common mistake is forgetting to make the constructor private. If the constructor is public, anyone can create multiple instances, defeating the purpose of the Singleton. Another mistake is not handling the instance creation thread-safely in a multi-threaded environment. You might need to use synchronization mechanisms (e.g., locks) in those cases.

The Factory Pattern

The Factory pattern provides an interface for creating objects, but lets subclasses decide which class to instantiate. This pattern is useful when you have a family of related objects and want to decouple the object creation logic from the client code. Let’s illustrate with a simple example.

Implementation

Suppose you’re building a system to create different types of vehicles. You can use the Factory pattern to handle the creation process.


// Product Interface
interface Vehicle {
  drive(): void;
}

// Concrete Products
class Car implements Vehicle {
  drive() {
    console.log("Car is driving.");
  }
}

class Bike implements Vehicle {
  drive() {
    console.log("Bike is cycling.");
  }
}

// Factory Interface
interface VehicleFactory {
  createVehicle(): Vehicle;
}

// Concrete Factories
class CarFactory implements VehicleFactory {
  createVehicle(): Vehicle {
    return new Car();
  }
}

class BikeFactory implements VehicleFactory {
  createVehicle(): Vehicle {
    return new Bike();
  }
}

// Client Code
function createAndDriveVehicle(factory: VehicleFactory) {
  const vehicle = factory.createVehicle();
  vehicle.drive();
}

// Example Usage:
createAndDriveVehicle(new CarFactory()); // Output: Car is driving.
createAndDriveVehicle(new BikeFactory()); // Output: Bike is cycling.

Explanation:

  • Product Interface (`Vehicle`): Defines the common interface for all vehicle types.
  • Concrete Products (`Car`, `Bike`): Implement the `Vehicle` interface.
  • Factory Interface (`VehicleFactory`): Defines the `createVehicle()` method.
  • Concrete Factories (`CarFactory`, `BikeFactory`): Implement the `VehicleFactory` interface and create specific vehicle types.
  • Client Code (`createAndDriveVehicle`): Uses the factory to create and drive vehicles without knowing the concrete classes.

Common Mistakes and Fixes

A common mistake is creating a monolithic factory that handles all possible object creation scenarios. This can lead to a bloated and hard-to-maintain factory class. Instead, create separate factories for each family of related objects, as shown in the example. Another potential pitfall is not defining a clear interface for the products. Always define an interface or abstract class to ensure that your products adhere to a consistent structure.

The Observer Pattern

The Observer pattern defines a one-to-many dependency between objects so that when one object (the subject) changes state, all its dependents (observers) are notified and updated automatically. This pattern is crucial for building systems where changes in one part of the system need to trigger updates in other parts, such as in event-driven architectures. Let’s look at how to implement this in TypeScript.

Implementation

Imagine a simple stock market application where you have a stock ticker (the subject) and multiple investors (the observers). The investors want to be notified when the stock price changes.


// Observer Interface
interface Observer {
  update(price: number): void;
}

// Subject Interface
interface Subject {
  attach(observer: Observer): void;
  detach(observer: Observer): void;
  notify(): void;
}

// Concrete Subject
class StockTicker implements Subject {
  private observers: Observer[] = [];
  private price: number;

  constructor(initialPrice: number) {
    this.price = initialPrice;
  }

  public attach(observer: Observer): void {
    this.observers.push(observer);
  }

  public detach(observer: Observer): void {
    this.observers = this.observers.filter((obs) => obs !== observer);
  }

  public notify(): void {
    for (const observer of this.observers) {
      observer.update(this.price);
    }
  }

  public setPrice(newPrice: number): void {
    this.price = newPrice;
    console.log(`Stock price changed to ${this.price}`);
    this.notify();
  }
}

// Concrete Observers
class Investor implements Observer {
  private name: string;

  constructor(name: string) {
    this.name = name;
  }

  public update(price: number): void {
    console.log(`${this.name} received an update. Stock price is now ${price}.`);
  }
}

// Example Usage:
const stock = new StockTicker(100);
const investor1 = new Investor("Alice");
const investor2 = new Investor("Bob");

stock.attach(investor1);
stock.attach(investor2);

stock.setPrice(105); // Alice received an update. Stock price is now 105. // Bob received an update. Stock price is now 105.
stock.setPrice(98);  // Alice received an update. Stock price is now 98. // Bob received an update. Stock price is now 98.

stock.detach(investor2);
stock.setPrice(102); // Alice received an update. Stock price is now 102.

Explanation:

  • Observer Interface (`Observer`): Defines the `update()` method that observers must implement.
  • Subject Interface (`Subject`): Defines methods for attaching, detaching, and notifying observers.
  • Concrete Subject (`StockTicker`): Manages the observers and notifies them when the stock price changes.
  • Concrete Observers (`Investor`): Implement the `Observer` interface and react to price changes.

Common Mistakes and Fixes

A common mistake is creating circular dependencies between the subject and the observers. Make sure that the subject doesn’t depend on the specific implementation of the observers. Another mistake is not handling observer registration and unregistration correctly. Ensure that you have methods to add and remove observers to prevent memory leaks and unexpected behavior.

The Strategy Pattern

The Strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. This pattern allows the algorithm to vary independently from the clients that use it. It is useful when you have multiple ways of doing something, and you want to choose the appropriate way at runtime. Let’s see how this works in TypeScript.

Implementation

Imagine you have a system that calculates shipping costs. You can use the Strategy pattern to implement different shipping methods (e.g., UPS, FedEx, USPS).


// Strategy Interface
interface ShippingStrategy {
  calculate(order: Order): number;
}

// Concrete Strategies
class UPS implements ShippingStrategy {
  calculate(order: Order): number {
    // Implementation for UPS shipping
    return order.weight * 0.5; // Example cost calculation
  }
}

class FedEx implements ShippingStrategy {
  calculate(order: Order): number {
    // Implementation for FedEx shipping
    return order.weight * 0.75; // Example cost calculation
  }
}

class USPS implements ShippingStrategy {
  calculate(order: Order): number {
    // Implementation for USPS shipping
    return order.weight * 0.4; // Example cost calculation
  }
}

// Context
class Order {
  weight: number;
  shippingStrategy: ShippingStrategy;

  constructor(weight: number, shippingStrategy: ShippingStrategy) {
    this.weight = weight;
    this.shippingStrategy = shippingStrategy;
  }

  public setShippingStrategy(shippingStrategy: ShippingStrategy): void {
    this.shippingStrategy = shippingStrategy;
  }

  public calculateShippingCost(): number {
    return this.shippingStrategy.calculate(this);
  }
}

// Example Usage:
const order1 = new Order(10, new UPS());
console.log(`UPS Shipping cost: ${order1.calculateShippingCost()}`);

order1.setShippingStrategy(new FedEx());
console.log(`FedEx Shipping cost: ${order1.calculateShippingCost()}`);

const order2 = new Order(5, new USPS());
console.log(`USPS Shipping cost: ${order2.calculateShippingCost()}`);

Explanation:

  • Strategy Interface (`ShippingStrategy`): Defines the `calculate()` method that all concrete strategies must implement.
  • Concrete Strategies (`UPS`, `FedEx`, `USPS`): Implement the `ShippingStrategy` interface and provide specific shipping cost calculations.
  • Context (`Order`): Holds a reference to a `ShippingStrategy` and delegates the cost calculation to it.

Common Mistakes and Fixes

A common mistake is tightly coupling the context to the concrete strategies. The context should only depend on the strategy interface, not the specific implementations. Another mistake is not providing a way to change the strategy at runtime. Make sure that the context has a method to set the strategy so that the client can choose the appropriate algorithm dynamically.

The Decorator Pattern

The Decorator pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. Instead of creating subclasses to add features, you can wrap the original object with decorator objects. This pattern is particularly useful when you need to add features to objects without modifying their core classes. Let’s see how this works in TypeScript.

Implementation

Consider a simple text editor application. You can use the Decorator pattern to add formatting options like bold, italics, and underline.


// Component Interface
interface TextComponent {
  getContent(): string;
}

// Concrete Component
class SimpleText implements TextComponent {
  private content: string;

  constructor(content: string) {
    this.content = content;
  }

  getContent(): string {
    return this.content;
  }
}

// Decorator Abstract Class
abstract class TextDecorator implements TextComponent {
  protected component: TextComponent;

  constructor(component: TextComponent) {
    this.component = component;
  }

  abstract getContent(): string;
}

// Concrete Decorators
class BoldText extends TextDecorator {
  getContent(): string {
    return `<b>${this.component.getContent()}</b>`;
  }
}

class ItalicText extends TextDecorator {
  getContent(): string {
    return `<i>${this.component.getContent()}</i>`;
  }
}

class UnderlineText extends TextDecorator {
  getContent(): string {
    return `<u>${this.component.getContent()}</u>`;
  }
}

// Example Usage:
const simpleText = new SimpleText("Hello, world!");
const boldText = new BoldText(simpleText);
const italicText = new ItalicText(boldText);
const underlinedText = new UnderlineText(italicText);

console.log(underlinedText.getContent()); // Output: <u><i><b>Hello, world!</b></i></u>

Explanation:

  • Component Interface (`TextComponent`): Defines the interface for the objects that can be decorated.
  • Concrete Component (`SimpleText`): The basic implementation of the text.
  • Decorator Abstract Class (`TextDecorator`): Implements the `TextComponent` interface and holds a reference to the component it decorates.
  • Concrete Decorators (`BoldText`, `ItalicText`, `UnderlineText`): Extend the `TextDecorator` and add specific formatting.

Common Mistakes and Fixes

A common mistake is not adhering to the component interface in the decorator classes. All decorators must implement the same interface as the component they decorate. Another mistake is creating complex decorator chains that are difficult to manage. Keep the decorator classes simple and focused on a single responsibility.

The Adapter Pattern

The Adapter pattern converts the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. This pattern is essential when integrating existing components with different interfaces or when you need to use a third-party library that doesn’t align with your system’s design. Let’s see how to implement it in TypeScript.

Implementation

Imagine you have a system that uses a specific interface for data retrieval, but you want to integrate a third-party library that uses a different interface. You can use the Adapter pattern to bridge the gap.


// Target Interface
interface Target {
  request(): string;
}

// Adaptee (Third-party class with an incompatible interface)
class Adaptee {
  specificRequest(): string {
    return "<specific>Special request</specific>";
  }
}

// Adapter
class Adapter implements Target {
  private adaptee: Adaptee;

  constructor(adaptee: Adaptee) {
    this.adaptee = adaptee;
  }

  request(): string {
    const result = this.adaptee.specificRequest();
    return `<target>${result}</target>`;
  }
}

// Client Code
function clientCode(target: Target) {
  console.log(target.request());
}

// Example Usage:
const adaptee = new Adaptee();
const adapter = new Adapter(adaptee);
clientCode(adapter); // Output: <target><specific>Special request</specific></target>

Explanation:

  • Target Interface (`Target`): Defines the interface that the client expects.
  • Adaptee (`Adaptee`): The class with the incompatible interface.
  • Adapter (`Adapter`): Implements the `Target` interface and adapts the `Adaptee`’s interface to match the `Target` interface.

Common Mistakes and Fixes

A common mistake is not clearly defining the target interface. Ensure that the target interface is well-defined and meets the needs of the client code. Another mistake is not considering the direction of the adaptation. In some cases, you might need a two-way adapter to convert between two incompatible interfaces.

The Command Pattern

The Command pattern encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. This pattern is useful when you need to decouple the invoker (the object that initiates the request) from the receiver (the object that performs the action). It’s also helpful for implementing features like undo/redo and transaction management. Let’s see how to implement it in TypeScript.

Implementation

Imagine a simple text editor with commands like “bold,” “italic,” and “underline.” The Command pattern can be used to encapsulate these operations.


// Command Interface
interface Command {
  execute(): void;
  undo(): void;
}

// Receiver (The object that performs the action)
class TextEditor {
  private text: string = "";

  setText(text: string): void {
    this.text = text;
  }

  getText(): string {
    return this.text;
  }

  bold(): void {
    this.text = `<b>${this.text}</b>`;
  }

  italic(): void {
    this.text = `<i>${this.text}</i>`;
  }

  underline(): void {
    this.text = `<u>${this.text}</u>`;
  }
}

// Concrete Commands
class BoldCommand implements Command {
  private editor: TextEditor;
  private previousText: string = "";

  constructor(editor: TextEditor) {
    this.editor = editor;
  }

  execute(): void {
    this.previousText = this.editor.getText();
    this.editor.bold();
  }

  undo(): void {
    this.editor.setText(this.previousText);
  }
}

class ItalicCommand implements Command {
  private editor: TextEditor;
  private previousText: string = "";

  constructor(editor: TextEditor) {
    this.editor = editor;
  }

  execute(): void {
    this.previousText = this.editor.getText();
    this.editor.italic();
  }

  undo(): void {
    this.editor.setText(this.previousText);
  }
}

class UnderlineCommand implements Command {
  private editor: TextEditor;
  private previousText: string = "";

  constructor(editor: TextEditor) {
    this.editor = editor;
  }

  execute(): void {
    this.previousText = this.editor.getText();
    this.editor.underline();
  }

  undo(): void {
    this.editor.setText(this.previousText);
  }
}

// Invoker (The object that executes the command)
class Button {
  private command: Command | null = null;

  setCommand(command: Command): void {
    this.command = command;
  }

  click(): void {
    if (this.command) {
      this.command.execute();
    }
  }

  undo(): void {
    if (this.command) {
      this.command.undo();
    }
  }
}

// Client Code
const editor = new TextEditor();
const boldCommand = new BoldCommand(editor);
const italicCommand = new ItalicCommand(editor);
const underlineCommand = new UnderlineCommand(editor);

const button = new Button();

editor.setText("Hello, world!");

button.setCommand(boldCommand);
button.click(); // <b>Hello, world!</b>
console.log(editor.getText());
button.undo(); // Hello, world!
console.log(editor.getText());

button.setCommand(italicCommand);
button.click(); // <i>Hello, world!</i>
console.log(editor.getText());
button.undo(); // Hello, world!
console.log(editor.getText());

button.setCommand(underlineCommand);
button.click(); // <u>Hello, world!</u>
console.log(editor.getText());
button.undo(); // Hello, world!
console.log(editor.getText());

Explanation:

  • Command Interface (`Command`): Defines the `execute()` and `undo()` methods.
  • Receiver (`TextEditor`): Performs the actual actions (e.g., bold, italic, underline).
  • Concrete Commands (`BoldCommand`, `ItalicCommand`, `UnderlineCommand`): Encapsulate the request and call the receiver’s methods.
  • Invoker (`Button`): Executes the command.

Common Mistakes and Fixes

A common mistake is tightly coupling the invoker to the concrete commands. The invoker should only work with the command interface. Another mistake is not implementing the `undo()` method correctly. The `undo()` method should restore the state of the receiver to its previous state before the command was executed.

The Bridge Pattern

The Bridge pattern decouples an abstraction from its implementation so that the two can vary independently. This pattern is useful when you want to avoid a permanent binding between an abstraction and its implementation. It allows you to change the implementation at runtime. Let’s explore how to implement it in TypeScript.

Implementation

Imagine you’re building a drawing application, and you want to support different drawing APIs (e.g., Canvas, SVG). The Bridge pattern can help you decouple the drawing abstraction from the specific API implementations.


// Abstraction
interface Shape {
  draw(): void;
}

// Implementor Interface
interface DrawingAPI {
  drawCircle(x: number, y: number, radius: number): void;
}

// Concrete Implementors
class CanvasAPI implements DrawingAPI {
  drawCircle(x: number, y: number, radius: number): void {
    console.log(`Drawing a circle on Canvas at (${x}, ${y}) with radius ${radius}`);
  }
}

class SvgAPI implements DrawingAPI {
  drawCircle(x: number, y: number, radius: number): void {
    console.log(`Drawing a circle on SVG at (${x}, ${y}) with radius ${radius}`);
  }
}

// Refined Abstraction
class Circle implements Shape {
  private x: number;
  private y: number;
  private radius: number;
  private drawingAPI: DrawingAPI;

  constructor(x: number, y: number, radius: number, drawingAPI: DrawingAPI) {
    this.x = x;
    this.y = y;
    this.radius = radius;
    this.drawingAPI = drawingAPI;
  }

  draw(): void {
    this.drawingAPI.drawCircle(this.x, this.y, this.radius);
  }
}

// Client Code
const canvasCircle = new Circle(10, 20, 5, new CanvasAPI());
const svgCircle = new Circle(30, 40, 10, new SvgAPI());

canvasCircle.draw(); // Drawing a circle on Canvas at (10, 20) with radius 5
svgCircle.draw(); // Drawing a circle on SVG at (30, 40) with radius 10

Explanation:

  • Abstraction (`Shape`): Defines the high-level interface (e.g., `draw()`).
  • Implementor Interface (`DrawingAPI`): Defines the interface for the implementation (e.g., `drawCircle()`).
  • Concrete Implementors (`CanvasAPI`, `SvgAPI`): Implement the `DrawingAPI` interface using specific drawing APIs.
  • Refined Abstraction (`Circle`): Implements the `Shape` interface and holds a reference to a `DrawingAPI`.

Common Mistakes and Fixes

A common mistake is not defining a clear interface for the implementor. The implementor interface should provide a well-defined set of methods that the abstraction can use. Another mistake is tightly coupling the abstraction to the concrete implementors. The abstraction should only depend on the implementor interface.

Key Takeaways

This tutorial has provided a comprehensive overview of several essential design patterns and their implementations in TypeScript. You’ve learned about the Singleton, Factory, Observer, Strategy, Decorator, Adapter, Command, and Bridge patterns, along with practical examples and common mistakes to avoid. By understanding and applying these patterns, you can significantly improve the quality, maintainability, and scalability of your TypeScript projects.

FAQ

Q: What are design patterns?

A: Design patterns are reusable solutions to commonly occurring problems in software design. They provide a blueprint for structuring code, making it easier to understand, modify, and extend.

Q: Why should I use design patterns?

A: Design patterns improve code readability, enhance maintainability, increase reusability, and boost scalability.

Q: How do I choose the right design pattern?

A: The choice of design pattern depends on the specific problem you’re trying to solve. Consider the structure of your code, the relationships between objects, and the desired flexibility and maintainability.

Q: Can I combine multiple design patterns?

A: Yes, you can often combine multiple design patterns to solve complex problems. However, be mindful of the added complexity and ensure that the patterns complement each other.

Q: Are there any tools to help with design patterns in TypeScript?

A: While there aren’t specific tools that automatically implement design patterns, TypeScript’s static typing and IDE support (e.g., auto-completion, refactoring tools) greatly assist in implementing and maintaining design patterns.

As you continue your journey in software development, remember that design patterns are not just theoretical concepts; they are practical tools that can significantly enhance your ability to build robust, scalable, and maintainable applications. Practice implementing these patterns in your projects, and you’ll soon find yourself naturally incorporating them into your coding style, leading to more elegant and efficient solutions.

More posts