DEV Community: Samuel Kollát

Beyond Basics: Designing Flexible and Extensible TypeScript Applications with Decorator Design Pattern

Samuel Kollát — Sun, 19 Mar 2023 14:51:43 +0000

The Decorator design pattern is a structural pattern that allows behavior to be added to an individual object at runtime without affecting the behavior of other objects from the same class. This blog post will explore how to use the Decorator pattern in Typescript and its benefits and drawbacks.

Note about the Decorators feature in Typescript

The Decorator design pattern and the Decorators feature in TypeScript are related concepts, but they have some key differences. The Decorators is a TypeScript feature that allows you to annotate classes and class members with decorator functions. These decorators are functions that can modify the behavior of a class or its members. One key difference between them is that the Decorator pattern is a well-established software design pattern that can be used in any programming language, while Decorators is a specific (experimental) feature of TypeScript.

Implementing the Decorator

Let's consider a simple example where we have a class called Shape with a method called draw. We want to add a border to the shape without changing the original code. We can achieve this using the Decorator pattern.

Let's start with an IShape interface and the Shape class that implements it.

interface IShape {
  draw(): void;
}

class Shape implements IShape {
  public draw(): void {
    console.log('Drawing a shape');
  }
}

Now, let's create a ShapeWithBorder class that will decorate the Shape class and will add a border to the shape. As the first step, the ShapeWithBorder class will implement the IShape interface.

class ShapeWithBorder implements IShape {
  private shape: IShape;

  constructor(shape: IShape) {
    this.shape = shape;
  }

  public draw(): void {
    console.log('Adding a border to the shape');
    this.shape.draw();
  }
}

As the second step, the ShapeWithBorder class accepts an object implementing the IShape interface in its constructor. This way we can provide any IShape compliant object to it, and the class will decorate this object with a border. Notice that because ShapeWithBorder implements IShape can also act as a decoration receiver. This way, we can add multiple decorators on top of each other, which we will explore in the next section.

Now, we can create an instance of the ShapeWithBorder class and pass an instance of the Shape class to its constructor. Finally, we call the draw method on the ShapeWithBorder instance, which will add a border to the shape and draw it.

const shape = new ShapeWithBorder(new Shape());

shape.draw();

You can find this example in this CodeSandbox.

Beyond Basics

Imagine you're building a system to generate reports for a finance company. You have a Report class that generates a basic report, but you want to add additional features to the report based on the user's preferences. For example, some users may want to see charts and graphs, while others may want to see tables of data. Instead of creating separate classes for each report type or using inheritance, you can use the Decorator pattern to add the required features at runtime.

First, let's define an interface for our Report class:

interface IReport {
  getData(): Record<number, number>;
  generate(): void;
}

Next, let's create a basic Report class that implements the interface:

class BasicReport implements IReport {
  constructor(private _data: Record<number, number>) {}

  public getData(): Record<number, number> {
    return this._data;
  }

  public generate(): void {
    console.log('Generating basic report...');
  }
}

Now, let's create two decorator classes, one for charts and one for tables:

class ReportWithCharts implements IReport {
  private report: IReport;

  constructor(report: IReport) {
    this.report = report;
  }

  public getData(): Record<number, number> {
    return this.report.getData();
  }

  public generate(): void {
    this.report.generate();

    console.log('Adding charts to report...');
    const data = this.report.getData();
    // Use data to generate charts...
  }
}

class ReportWithTables implements IReport {
  private report: IReport;

  constructor(report: IReport) {
    this.report = report;
  }

  public getData(): Record<number, number> {
    return this.report.getData();
  }

  public generate(): void {
    this.report.generate();

    console.log('Adding tables to report...');
    const data = this.report.getData();
    // Use data to generate the tables...
  }
}

Finally, we can create an instance of the BasicReport class and pass it through the decorator classes to add the required features:

const now = Date.now()
const sampleData = {
  [now-2]: 123,
  [now-1]: 456,
  [now]: 789,
}

const report: IReport = new ReportWithCharts(
  new ReportWithTables(new BasicReport(sampleData))
);

report.generate();

You can find the full example in this CodeSandbox.

This will generate a report with charts and tables, but you can easily modify it to generate a report with only charts or only tables by removing the corresponding decorator classes.

We can also create new decorator classes for additional features without modifying the existing code, which makes it easier to maintain and extend the system over time.

Benefits

Flexibility: The pattern provides a flexible way to add behavior to an object at runtime. It allows you to add or remove behavior without changing the original code, making it easier to maintain.
Reusability: Decorators can be reused on different objects to add the same behavior, making the code more efficient and reducing the need to write duplicate code.
Separation of concerns: Separating an advanced or optional behavior of an object from its core functionality.

Drawbacks

Complexity: Using the Decorator pattern can make the code more complex, especially when dealing with multiple decorators.
Performance: Adding behavior at runtime can affect the performance of your code. It all depends on how the decorators and the core class are implemented. It is important to avoid the N+1 problem, which can be created by executing the core class for each decorator that encapsulates it within the single chain.

In conclusion, the Decorator pattern is a valuable design pattern that can be used in Typescript to add behavior to an object at runtime without affecting other objects of the same class. It provides flexibility, reusability, and separation of concerns. However, it can also make the code more complex and affect performance. By following the examples outlined in this blog post, you can effectively implement the Decorator pattern in your Typescript code.

Photo by Martin Sanchez on Unsplash

Beyond Basics: Streamline Your Typescript Code With Fluent Interface Design Pattern

Samuel Kollát — Fri, 10 Mar 2023 13:27:52 +0000

The Fluent Interface is a design pattern used to create object-oriented APIs that are easy to read and use. It allows developers to write code that reads like natural language. It achieves this by chaining multiple method calls together, resulting in a more readable, expressive, and intuitive syntax.

The principle behind the Fluent Interface is to allow developers to create a series of small, easy-to-read method calls that can be chained together. Each method call returns an instance of the object it was called on, allowing the developer to call the next method in the chain on the returned object.

Implementing Fluent Interface

Let's look at a simple example to illustrate how the Fluent Interface pattern works in Typescript:

class Person {
  private firstName: string;
  private lastName: string;
  private age: number;

  setFirstName(firstName: string): Person {
    this.firstName = firstName;
    return this;
  }

  setLastName(lastName: string): Person {
    this.lastName = lastName;
    return this;
  }

  setAge(age: number): Person {
    this.age = age;
    return this;
  }

  getInfo(): string {
    return `Name: ${this.firstName} ${this.lastName}, Age: ${this.age}`;
  }
}

const person = new Person()
  .setFirstName('John')
  .setLastName('Doe')
  .setAge(30);

console.log(person.getInfo()); // Name: John Doe, Age: 30

Example in CodeSandbox.

As you can see, each fluent method in the Person class returns this, which is a reference to itself. As it is also an instance of Person class, we can access all methods available on Person class again.

Beyond Basics

Now let's look at how we can implement the Fluent Interface in our own variation of one of the most popular testing libraries for JavaScript and TypeScript applications - Jest. Jest mimics the Fluent Interface pattern in its expect method to provide a more natural and intuitive syntax for writing assertions in tests.

The expect method in Jest takes an actual value and returns an object that allows developers to make various assertions on that value. Here's an example of how it can be used:

test('should return the correct sum of two numbers', () => {
  const result = sum(2, 3);
  expect(result).not.toBe(6);
});

Here we use the expect method to assert the result of a sum function. We chain the not and toBe method onto the object returned by expect to assert that the result of the sum method is not equal to the number 6.

Now let's look at how we could implement the expect method and underlying Expect class using the Fluent Interface pattern:

class Expect<T> {
  constructor(private actual: T) {}

  toBe(expected: T): this {
    if (this.actual !== expected) {
      throw new Error(`Expected ${expected}, but got ${this.actual}`);
    }
    return this;
  }

  not: NotExpect<T> = new NotExpect(this.actual);

  // other assertion methods...
}

class NotExpect<T> {
  constructor(private actual: T) {}

  toBe(expected: T): this {
    if (this.actual === expected) {
      throw new Error(`Expected ${expected} not to be ${this.actual}`);
    }
    return this;
  }

  // other assertion methods...
}

function expect<T>(actual: T): Expect<T> {
  return new Expect<T>(actual);
}

See the example in this CodeSandbox.

In this implementation, the not method is a member of the Expect class that returns a new instance of the NotExpect class. The NotExpect class has similar assertion methods to the Expect class, but all of its assertion methods negate the assertion.

The toBe method in the NotExpect class checks that the actual value is not equal to the expected value. If the values are equal, the method throws an error with a negated error message.

Benefits

Benefits of Fluent Interface Pattern:

Readability: The Fluent Interface pattern improves the readability of code by providing a more natural and intuitive syntax.
Chaining: The pattern allows developers to chain multiple method calls, resulting in more concise and easy-to-read code.
Flexibility: The pattern provides flexibility in creating and configuring objects.

Drawbacks

The main two drawbacks of the Fluent Interface Pattern are overuse and with it connected issues with maintainability:

Overuse: The Fluent Interface pattern can be overused, resulting in code that is difficult to read and maintain. Do not use this pattern in every place where it can be used, but reserve it for cases where it makes sense. Such cases can be, as in our example, fluent assertions or builders for complex objects that can have many ways of the optional configuration of their internal state.
Maintainability: Adding new functionality to a fluent interface means extending the class that implements it. This might result in large classes with many methods if the interface grows. In that case, it is important to carefully split the class into multiple sub-groups and create an abstraction on top of them that connects them, so the interface can still be used fluently.

When used appropriately, the Fluent Interface pattern can result in code that is easier to read, write, and maintain. It is especially useful in testing libraries, where readability and ease of use are critical. Overall, the Fluent Interface pattern is a valuable tool in every developer's toolkit and is worth considering when designing applications.

Photo by Christopher Gower on Unsplash

Beyond Basics: Building Scalable TypeScript Applications with Chain of Responsibility Design Pattern

Samuel Kollát — Wed, 08 Mar 2023 21:49:24 +0000

Chain of Responsibility (CoR) is a behavioral design pattern that passes a request between a chain of objects. In this pattern, each object in the chain can either handle the request or pass it on to the next object in the chain.

Today we will explore how to implement this design pattern in TypeScript.

Using CoR in TypeScript can simplify complex request processing, especially when the chain of objects needs to be changed or extended dynamically. The main idea behind this pattern is to decouple the sender of a request from its receiver by allowing more than one object to handle the request.

Implementing Chain of Responsibility

Let's start with a simple example to understand how the CoR pattern works in TypeScript. Let's say we have a series of objects that need to process a request for a certain document type. In this case, we can create a chain of objects that will handle the request, as shown below:

interface DocumentHandler {
  setNext(handler: DocumentHandler): DocumentHandler;
  handle(documentType: string): string;
}

Now we will create new classes named PDFHandler and TextHandler that implement DocumentHandler interface:

class PDFHandler implements DocumentHandler {
  private nextHandler: DocumentHandler;

  setNext(handler: DocumentHandler): DocumentHandler {
    this.nextHandler = handler;
    return handler;
  }

  handle(documentType: string): string {
    if (documentType === 'pdf') {
      return `Handling PDF Document`;
    } else if (this.nextHandler) {
      return this.nextHandler.handle(documentType);
    } else {
      return `Cannot Handle Document Type: ${documentType}`;
    }
  }
}

class TextHandler implements DocumentHandler {
  private nextHandler: DocumentHandler;

  setNext(handler: DocumentHandler): DocumentHandler {
    this.nextHandler = handler;
    return handler;
  }

  handle(documentType: string): string {
    if (documentType === 'text') {
      return `Handling Text Document`;
    } else if (this.nextHandler) {
      return this.nextHandler.handle(documentType);
    } else {
      return `Cannot Handle Document Type: ${documentType}`;
    }
  }
}

Each class can handle a specific type of document. If a class cannot handle the request, it passes it to the next object in the chain. We can create a chain of objects by calling the setNext() method on each object and passing in the next object in the chain:

const pdfHandler = new PDFHandler();
const textHandler = new TextHandler();

pdfHandler.setNext(textHandler);

console.log(pdfHandler.handle('pdf')); // Output: Handling PDF Document
console.log(pdfHandler.handle('text')); // Output: Handling Text Document
console.log(pdfHandler.handle('excel')); // Output: Cannot Handle Document Type: excel

You can find the complete example in this CodeSandbox.

We can see from the output that the request for each document type is handled by the appropriate object in the chain. If the request cannot be handled by any of the objects in the chain, the last object in the chain returns a message indicating that it cannot handle the request.

Beyond Basics

Now let's look at a real-world example of using the CoR pattern in a web application that processes payments. The payment processing system can have different payment methods, such as credit cards, PayPal, and bank transfers. Each payment method can have different authentication and validation requirements.

To implement this system using the CoR pattern, we can create a chain of objects representing payment methods. Let's start again with the interface and some types:

export type PaymentMethod = "creditcard" | "paypal" | "banktransfer";

export type Payment = {
  method: PaymentMethod;
  amount: number;
  cardNumber: string;
  cvv: string;
  expirationDate: string;
};

interface PaymentHandler {
  setNext(handler: PaymentHandler): PaymentHandler;
  handlePayment(payment: Payment): Promise<boolean>;
}

Each object that implements the PaymentHandler interface can authenticate and validate the corresponding payment method. If an object cannot handle the request, it passes the request to the next object in the chain:

class CreditCardHandler implements PaymentHandler {
  private nextHandler: PaymentHandler;

  setNext(handler: PaymentHandler): PaymentHandler {
    this.nextHandler = handler;
    return handler;
  }

  async handlePayment(payment: Payment): Promise<boolean> {
    if (payment.method === 'creditcard') {
      console.log('Processing Credit Card Payment...');
      return true;
    } else if (this.nextHandler) {
      return this.nextHandler.handlePayment(payment);
    } else {
      return false;
    }
  }
}

class PayPalHandler implements PaymentHandler {
  private nextHandler: PaymentHandler;

  setNext(handler: PaymentHandler): PaymentHandler {
    this.nextHandler = handler;
    return handler;
  }

  async handlePayment(payment: Payment): Promise<boolean> {
    if (payment.method === 'paypal') {
      console.log('Processing PayPal Payment...');
      return true;
    } else if (this.nextHandler) {
      return this.nextHandler.handlePayment(payment);
    } else {
      return false;
    }
  }
}

class BankTransferHandler implements PaymentHandler {
  private nextHandler: PaymentHandler;

  setNext(handler: PaymentHandler): PaymentHandler {
    this.nextHandler = handler;
    return handler;
  }

  async handlePayment(payment: Payment): Promise<boolean> {
    if (payment.method === 'banktransfer') {
      console.log('Processing Bank Transfer Payment...');
      return true;
    } else if (this.nextHandler) {
      return this.nextHandler.handlePayment(payment);
    } else {
      return false;
    }
  }
}

In this example, three classes implement the PaymentHandler interface. Each class represents a payment method and handles the authentication and validation for that payment method. We create a chain of objects by calling the setNext() method on each object and passing in the next object in the chain:

const creditCardHandler = new CreditCardHandler();
const payPalHandler = new PayPalHandler();
const bankTransferHandler = new BankTransferHandler();

creditCardHandler.setNext(payPalHandler).setNext(bankTransferHandler);

const payment: Payment = {
  method: 'creditcard',
  amount: 100,
  cardNumber: '1234567890',
  cvv: '111',
  expirationDate: '01/24'
};

const isPaymentSuccessful = await creditCardHandler.handlePayment(payment);

console.log('Payment Successful:', isPaymentSuccessful);

You can find the complete example in this CodeSandbox.

We can see from the output that the payment request is handled by the appropriate object in the chain based on the payment method. If the payment method cannot be handled by any of the objects in the chain, the last object in the chain returns false.

Middleware in web servers

One great example of using the CoR pattern is the handling of HTTP requests through middlewares in web servers. Let's take an example of Express.js, a very popular Node.js framework. In Express.js, middlewares functions have access to the request object, the response object, and the next middleware in the application’s request-response cycle. Middleware functions can perform tasks such as parsing the request body, handling authentication, performing validation, and many more.

When a request is made to an application, the middleware functions are executed in the order they are defined. Each middleware function can perform operations on the request and/or response objects and pass control to the next middleware function in the chain using the next() function. If a middleware function doesn't call next(), the request-response cycle is terminated, and no further middleware functions are executed.

Middleware functions can be added to or removed from the chain at any point, allowing developers to modify the behavior of their applications easily.

Let's look at an example:

const express = require('express');
const app = express();

// 1. Middleware for parsing a request
app.use((req, res, next) => {
  console.log('Parsing...');
  next();
});

// 2. Middleware for authenticating a request
app.use((req, res, next) => {
  console.log('Authenticating...');
  next();
});

// 3. Route handler middleware for sending a response
app.get('/', (req, res) => {
  res.send('Sending response...');
});

app.listen(3000, () => {
  console.log('Server listening...');
});

In this example, two middleware functions are defined using the app.use() and one using app.get() function. The first middleware function logs a message to the console and calls next() to pass control to the next middleware function. The second middleware function does the same. Finally, a route handler sends a response back to the client. When a request is made to the server, the middleware functions are executed in the order they are defined.

Benefits

Benefits of using the CoR pattern:

Encapsulation: The CoR pattern promotes encapsulation by separating the code that creates a request from the code that handles the request. This makes the code more modular and easier to maintain.
Flexibility: The pattern allows you to easily add, remove or reorder the chain of handlers without affecting other parts of the code. This makes it easier to modify the behavior of an application or add new features.
Extensibility: The pattern makes adding new handlers to the chain easy, allowing you to extend the functionality of an application without modifying existing code.
Decoupling: The pattern reduces the dependencies between classes, which makes the code more loosely coupled and easier to test.

Drawbacks

Here are some aspects of the CoR pattern that should be taken into account when evaluating if it fits your application needs:

Performance: The CoR pattern can introduce performance overhead if the chain of handlers is long or if the handlers are complex.
Difficulty in debugging: The pattern can make it harder to trace the flow of a request through the application, especially if the chain of handlers is long.
Complexity: The pattern can make the code more complex and harder to understand, especially if there are many different types of requests and handlers.

The Chain of Responsibility pattern is a useful pattern for handling requests in a flexible and extensible way. It allows multiple objects to handle requests by chaining them together, and it provides a way to add or remove objects from the chain without affecting the other objects. However, it is important to be aware of both the benefits and drawbacks that may arise when using this pattern.

Photo by FLY:D on Unsplash

Beyond Basics: Transform Your Typescript Codebase with Command Design Pattern

Samuel Kollát — Mon, 06 Mar 2023 23:11:16 +0000

The design pattern Command is a behavioral design pattern that encapsulates requests as objects. The primary purpose of the pattern is to separate a request from its execution, thus allowing a more flexible and modular design. This pattern is especially useful in applications that need:

UI to interact with complex business logic
Undo/redo functionality
Transactional behavior with rollback

In this blog post, we will explore how to use the Command pattern in Typescript and its benefits and drawbacks.

Implementing the Command pattern

Let's start with a simple example to illustrate the Command pattern. Suppose we have a simple calculator application that supports adding and subtracting numbers. We can use the Command pattern to encapsulate these operations as commands.

First, we need to define the Command interface:

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

This interface defines two methods: execute() and undo(). As their names suggest, the execute() method is used to execute the command, while the undo() method is used to undo the command.

Next, we can define the AddCommand and SubtractCommand classes that implement the interface:

class AddCommand implements Command {
  constructor(
    private calculator: Calculator,
    private value: number
  ) {}

  execute(): void {
    this.calculator.add(this.value);
  }

  undo(): void {
    this.calculator.subtract(this.value);
  }
}

class SubtractCommand implements Command {
  constructor(
    private calculator: Calculator, 
    private value: number
  ) {}

  execute(): void {
    this.calculator.subtract(this.value);
  }

  undo(): void {
    this.calculator.add(this.value);
  }
}

As you can see, the execute() method calls the corresponding method on the calculator object, while the undo() method reverses the operation. The important part to notice is that both classes encapsulate behavior relevant to their operation. Nothing less, nothing more.

Finally, we can define the Calculator class:

class Calculator {
  private value = 0;

  add(value: number): void {
    this.value += value;
  }

  subtract(value: number): void {
    this.value -= value;
  }
}

The Calculator class represents the receiver in the Command pattern and provides the add and subtract operations.

Now we can use our implementation of the Command pattern to add and subtract numbers:

const calculator = new Calculator();

const addCommand = new AddCommand(calculator, 5);
const subtractCommand = new SubtractCommand(calculator, 3);

addCommand.execute(); // calculator value is now 5
subtractCommand.execute(); // calculator value is now 2

// undo subtract command
subtractCommand.undo(); // calculator value is now 5

// undo add command
addCommand.undo(); // calculator value is now 0

In this example, we create instances of the AddCommand and SubtractCommand classes and pass them the Calculator object and values to add or subtract. We then execute the commands using the execute() method, which calls the corresponding method on the calculator object. Finally, we undo the commands using the undo() method, which reverses the operation and returns the calculator to its initial state.

You can find the full example in this CodeSandbox.

Of course, this simple implementation has some flaws; for example, you can undo a command without ever calling execute() method. Make sure to handle such cases when using the pattern in your applications.

Beyond Basics

Let's look at a more practical example of the Command pattern in Typescript. That can be the implementation of an e-commerce application. Suppose we have an application that allows users to add, remove, and modify items in their shopping cart. We can use the Command pattern to encapsulate these operations as commands.

First, let's define the Command interface the same as we did before:

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

Next, we can define the concrete command classes. Let's start with AddToCartCommand and RemoveFromCartCommand:

class AddToCartCommand implements Command {
  constructor(
    private cart: Cart,
    private item: Item
  ) {}

  execute(): void {
    this.cart.add(this.item);
  }

  undo(): void {
    this.cart.remove(this.item);
  }
}

class RemoveFromCartCommand implements Command {
  constructor(
    private cart: Cart, 
    private item: Item
  ) {}

  execute(): void {
    this.cart.remove(this.item);
  }

  undo(): void {
    this.cart.add(this.item);
  }
}

Same as with the Calculator, the straightforward encapsulation of adding and removing items from a cart. Now we can proceed with a more complex modification operation that allows modifying the number of items of the same kind in the cart.

class ModifyCartItemCommand implements Command {
   private previousItemQuantity: number;

  constructor(
    private cart: Cart, 
    private item: Item, 
    private newQuantity: number
  ) {}

  execute(): void {
    this.previousItemQuantity = this.cart.modify(this.item, this.newQuantity);
  }

  undo(): void {
    this.cart.modify(this.item, this.previousItemQuantity);
  }
}

The important part here is that a command, like any other object, can hold a state, in our case previousItemQuantity. If we take an example of a command that implements one step in a transaction, the internal state can hold the state change for that transaction. In case the transaction as a whole fails, the orchestrating logic can revert all the operations within that transaction, keeping the consistency in the system and atomicity of the transaction itself.

Finally, we can define the Item and Cart classes:

class Item {
  constructor(
    public id: number, 
    public name: string, 
    public price: number
  ) {}
}

class Cart {
  private items: Item[] = [];

  add(item: Item): void {
    this.items.push(item);
  }

  remove(item: Item): void {
    this.items = this.items.filter((i) => i.id !== item.id);
  }

  modify(item: Item, newQuantity: number): number {
    const previousQuantity = item.quantity;
    item.quantity = newQuantity;
    return previousQuantity;
  }
}

The Cart itself holds its internal state in an array of Items and individual commands operate on top of Cart's public methods.

Now we can use the Command pattern to add, remove, and modify items in the shopping cart:

const cart = new Cart();
const book = new Item(1, "Book", 10);
const movie = new Item(2, "Movie", 20);

const addBookCommand = new AddToCartCommand(cart, book);
const removeBookCommand = new RemoveFromCartCommand(cart, book);
const modifyBookCommand = new ModifyCartItemCommand(cart, book, 2);
const addMovieCommand = new AddToCartCommand(cart, movie);

addBookCommand.execute(); // cart now contains book
addMovieCommand.execute(); // cart now contains book and movie
removeBookCommand.execute(); // cart now contains only movie
addMovieCommand.undo(); // cart is empty
removeBookCommand.undo(); // cart now again contains book
modifyBookCommand.execute(); // cart now contains 2 books
modifyBookCommand.undo(); // cart now again contains only 1 book

In this example, we create instances of the AddToCartCommand, RemoveFromCartCommand, and ModifyCartItemCommand classes and pass them the cart object and items to add, remove, or modify. We then execute the commands using the execute() and undo() methods, which calls the corresponding methods on the cart object.

You can find the complete example in this CodeSandbox.

Benefits

The Command pattern offers several benefits, including:

Encapsulation: The Command pattern encapsulates the request as an object, which allows us to decouple the sender and receiver of the request. This separation of a request from its execution allows for a more flexible and modular design. Adding, removing, or modifying commands without affecting the rest of the code is easy.
Undo/redo functionality: By encapsulating requests as objects, the Command pattern makes it easy to implement undo/redo functionality. Each command object can store its state, making it possible to undo or redo a series of commands.
Decoupling: The Command pattern decouples the client from the receiver, making it possible to change the receiver without affecting the client. This also makes it easier to test the application since the client and receiver can be tested separately.

Drawbacks

Let's talk about the drawbacks of the Command pattern. It's important to always evaluate your particular use case and decide if this architectural approach makes sense.

Complexity: The pattern can add complexity to the system design, especially if many commands need to be implemented. If your application contains many small commands this can introduce code overhead.
Memory usage: The pattern can lead to increased memory usage, especially if each command object needs to store a large amount of data. It is essential to decide how many undo/redo operations are allowed so your application only stores the state of commands that still makes sense to undo/redo.
Performance: The pattern can impact performance, especially if many commands need to be executed or undone.

The Command pattern is a useful design pattern that provides a flexible way to implement complex operations by breaking them down into smaller, simpler commands. Typescript provides strong typing and other features that make it well-suited for implementing the Command pattern. By its usage, we can improve the decoupling, flexibility, and testability of our code. However, we should also be aware of the potential drawbacks, including increased complexity, performance, and overhead.

Photo by hannah joshua on Unsplash

Beyond Basics: Level Up Your TypeScript Skills with Visitor Design Pattern

Samuel Kollát — Sat, 04 Mar 2023 13:53:56 +0000

Visitor design pattern is a powerful object-oriented behavioral design pattern that allows you to separate algorithms from the objects they operate on.

In this pattern, we can define a set of operations to be performed on the elements of an object structure without changing the classes on which they operate. In this blog post, we'll discuss using the visitor pattern in TypeScript.

Implementing the visitor pattern

First, let's look at an example of how the visitor pattern can be used. Imagine that you are developing an e-commerce platform that needs to calculate the total cost of a customer's shopping cart, which may contain different types of items such as books and electronics. Each type of item may have its price calculation logic based on different factors. In our case, the price will differ between weekdays and weekends.

Let's start with a simple ShoppingCart implementation.

class ShoppingCart {
  items: Item[] = [];

  addItem(item: Item) {
    this.items.push(item);
  }

  getTotalPrice(visitor: ShoppingCartVisitor) {
    let total = 0;
    for (let item of this.items) {
      total += item.accept(visitor);
    }
    return total;
  }
}

We can add a new item to the shopping cart via addItem method, but more importantly, when calculating the cart's total price, we can pass a visitor object to getTotalPrice.

The different visitors can contain different price calculation algorithms, thus decoupling them from the objects they operate on. Let's look at how to achieve it by first defining an abstract class for shopping items and then two concrete shopping items - Book and Electronic.

abstract class Item {
  abstract accept(visitor: ShoppingCartVisitor): number;
}

class Book extends Item {
  price: number;

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

  accept(visitor: ShoppingCartVisitor) {
    return visitor.visitBook(this);
  }
}

class Electronic extends Item {
  price: number;
  weight: number;

  constructor(price: number, weight: number) {
    super();
    this.price = price;
    this.weight = weight;
  }

  accept(visitor: ShoppingCartVisitor) {
    return visitor.visitElectronic(this);
  }
}

The abstract class defines a single abstract method accept that each concrete shopping item that inherits this class has to implement. This enables each class to accept a visitor, thus allowing different algorithms to operate on this class.

Now we need to define an interface for shopping card visitors so each has the same code shape.

interface ShoppingCartVisitor {
  visitBook(book: Item): number;
  visitElectronic(electronic: Item): number;
}

As the first implementation of the visitor interface, we will choose the WeekdayVisitor. It does not apply any discounts and simply returns the original prices of items.

class WeekdayVisitor implements ShoppingCartVisitor {
  visitBook(book: Book) {
    return book.price;
  }

  visitElectronic(electronic: Electronic) {
    return electronic.price;
  }
}

As for the WeekendVisitor, let's add a different algorithm for price calculation. We will apply a 10% discount to books and a discount calculated from their weight for electronics.

class WeekendVisitor implements ShoppingCartVisitor {
  visitBook(book: Book) {
    // 10% discount on books during weekends
    return book.price * 0.9;
  }

  visitElectronic(electronic: Electronic) {
    // Discount based on weight of a electronic
    return electronic.price - electronic.weight * 0.1;
  }
}

And now, we can get the total price of the shopping cart based on different days of the week by applying a visitor of choice.

const cart = new ShoppingCart();

cart.addItem(new Book(5));
cart.addItem(new Book(10));
cart.addItem(new Electronic(100, 20));

// Weekdays
const weekdayVisitor = new WeekdayVisitor();
const weekdaysTotalPrice = cart.getTotalPrice(weekdayVisitor);
console.log(weekdaysTotalPrice); // output: 115

// Weekends
const weekendVisitor = new WeekendVisitor();
const weekendTotalPrice = cart.getTotalPrice(weekendVisitor);
console.log(weekendTotalPrice); // output: 111.5

As you can see, this pattern allows us to apply different algorithms based on some criteria, in our case, the day of the week, to the same data set. You can explore the complete example in this CodeSandbox.

Beyond Basics: Abstract syntax trees

One practical use of the visitor pattern in programming is working with abstract syntax trees (ASTs). ASTs represent the structure of code or an expression in a way that programs can easily manipulate and analyze. The visitor pattern is a natural fit for working with ASTs because it allows you to traverse the AST and perform operations on its nodes without modifying them.

In the following example, we'll define two types of nodes in the AST, BinaryOperationNode and NumberNode, and an interface for visiting these nodes named AstVisitor.

interface Node {
  accept(visitor: AstVisitor): number;
}

class BinaryOperationNode implements Node {
  constructor(private left: Node, private operator: string, private right: Node) {}

  accept(visitor: AstVisitor): number {
    return visitor.visitBinaryOperation(this);
  }

  getLeft(): Node {
    return this.left;
  }

  getOperator(): string {
    return this.operator;
  }

  getRight(): Node {
    return this.right;
  }
}

class NumberNode implements Node {
  constructor(private value: number) {}

  accept(visitor: AstVisitor): number {
    return visitor.visitNumber(this);
  }

  getValue(): number {
    return this.value;
  }
}

Now it's time to define a concrete visitor implementation called ExpressionEvaluator, which evaluates the expression represented by the AST. Notice how the visitBinaryOperation method first evaluates the left and right subtrees. This tree traversal method is called Post-order traversal, or LRN as in Left-Right-Node, and is one of the Depth-first search tree traversal methods.

interface AstVisitor {
  visitBinaryOperation(node: Node): number;
  visitNumber(node: Node): number;
}

class ExpressionEvaluator implements AstVisitor {
  visitBinaryOperation(node: BinaryOperationNode): number {
    const left = node.getLeft().accept(this);
    const right = node.getRight().accept(this);

    switch (node.getOperator()) {
      case '+':
        return left + right;
      case '-':
        return left - right;
      case '*':
        return left * right;
      case '/':
        return left / right;
      default:
        throw new Error(`Unknown operator ${node.getOperator()}`);
    }
  }

  visitNumber(node: NumberNode): number {
    return node.getValue();
  }
}

Finally, we create an AST representing the arithmetic expression 2 + (3 * 4) and traverse it using the visitor to evaluate the expression.

const expressionAst = new BinaryOperationNode(
  new NumberNode(2),
  '+',
  new BinaryOperationNode(
    new NumberNode(3),
    '*',
    new NumberNode(4)
  )
);

const expressionEvaluator = new ExpressionEvaluator();

const result = expressionAst.accept(expressionEvaluator);

console.log(result); // output: 14

See the complete example in this CodeSandbox.

This way, we can have many different algorithms traverse the AST. Imagine algorithms that analyze the AST for optimization purposes, logical errors, performing transpilation to other structures, etc. All these algorithms can operate on top of the same AST.

Benefits

Let's summarize the three main benefits of the visitor pattern:

Separation of Concerns: The visitor pattern separates algorithms from the objects on which they operate. This separation of concerns makes it easy to add new operations or algorithms without modifying the classes of the objects on which they operate.
Open-Closed Principle: The visitor pattern follows the open-closed principle, meaning classes should be open for extension but closed for modification. By using the visitor pattern, you can add new operations or algorithms to an existing object structure without modifying the classes of the objects, thus making your code extensible and flexible.
Maintainability: The visitor pattern makes it easy to maintain code by separating the operations or algorithms from the objects on which they operate. This separation makes understanding and modifying the code more straightforward, as each class has a single responsibility, leading to better code organization.

Drawbacks

Like any programming pattern, the visitor pattern also has its drawbacks. It is essential to know if applying the visitor pattern to your codebase allows you to leverage the benefits it brings or because of the nature of your code and objects on which the visitor would operate, the pattern would have more downside than upside. Some of the drawbacks of the visitor pattern are:

Complexity: The visitor pattern can add complexity to your code, especially when it involves multiple visitors and visitable classes. This can make your code harder to read and maintain.
Coupling: The visitor pattern can create a tight coupling between the visitors and the visitable classes. Suppose you need to modify the structure of the visitable classes. In that case, you may also need to modify the visitors, which can lead to a ripple effect of changes throughout your codebase.
Inflexibility: The visitor pattern can make your code less flexible because it requires the visitable classes to define a fixed set of methods for visitors to use. This can make it harder to add new functionality to your code in the future.

In summary, the visitor pattern provides several benefits when used in programming, including separation of concerns, adherence to the open-closed principle, and better code organization. In TypeScript, it's easy to implement the visitor pattern by defining a visitor interface, the visitor, the element interface, and the elements. By using the visitor pattern, you can create more flexible and maintainable code that's easier to extend and modify over time.

Photo by Milad Fakurian on Unsplash