Thoughts about SOLID - The Letter "L"
Tags: solidprinciples, programming, designpatterns, typescript
Published: 2024-05-18 20:32:57

In this fourth part of my thoughts, we continue with the letter "L", following the order proposed by the SOLID acronym. I'll be working with TypeScript in the examples.

---

## In this article

[Liskov Substitution Principle](#liskov-substitution-principle)
[Abstract example](#abstract-example)
[Technical example (Front-End)](#technical-example-frontend)
[Technical example (Back-End)](#technical-example-backend)
[Personal example](#personal-example)
[Functional example](#functional-example)
[Applicabilities](#applicabilities)
[Final thoughts](#final-thoughts)

---

## Liskov Substitution Principle

The Liskov Substitution Principle is named after Barbara Liskov, who originally described it. This principle proposes that **a class can be replaced by its subclasses without affecting the behavior of the system**.

Initially, let's set aside the **reason** why you would need to replace a class with a derived subclass and focus on applicabilities. Consider the following scenario:

- I have a class called `Class`;
- I have a subclass called `Subclass` that extends `Class`;
- I have an object `const obj = new Class()`;
- If I want to switch to `const obj = new Subclass()`, it should still work;

That's the practical summary of the principle. Now, let's move on to some examples.

---

## Abstract example

Imagine that, extending from our **Book** class, we identify books that are **incomplete**. However, the superclass expects there to be a quantity of books sold - functionality that was "lost" in the subclass.

**🔴 Incorrect Implementation**

Imagine que, estendendo da nossa classe de **livro**, identificamos livros que **não estão completos**. Contudo, a classe superiora espera que exista uma quantidade de livros vendidos - funcionalidade que foi "perdida" na subclasse.

```typescript
// We have our class for the book entity.
class Book {
  private sales: number;

  constructor(private title: string, private author: string) {}

  // We can set how many sales the book has.
  public setSales(sales: number) {
    this.sales = sales;
  }

  // And we can check how many sales the book has.
  public checkSales() {
    console.log(
      `The book "${this.title}" by "${this.author}" has sold ${this.sales} copies!`
    );
  }
}

class IncompleteBook extends Book {
  // VIOLATION OF THE PRINCIPLE: As an incomplete book has no sales, an error is returned here.
  // In other words, it wouldn't be possible to replace a Book instance with an IncompleteBook without
  // causing some unexpected side effects.
  public checkSales() {
    // Let's not dwell on the fact that we're literally causing an error here.
    // It's an abstract example.
    throw new Error(
      "This book has not yet been completed, therefore, it has no sales!"
    );
  }
}

const book = new Book("The Time Machine", "H. G. Wells");
book.setSales(50000000);
book.checkSales();

const incompleteBook = new IncompleteBook("The Time Machine", "H. G. Wells");
incompleteBook.setSales(50000000);
incompleteBook.checkSales(); // Here, it will throw an error. Literally, of course, because of what we did.
```

**🟢 Correct Implementation**

```typescript
class Book {
  private sales: number;

  constructor(private title: string, private author: string) {}

  public setSales(sales: number) {
    this.sales = sales;
  }

  public checkSales() {
    console.log(
      `O livro "${this.title}" de "${this.author}" vendeu ${this.sales} exemplares!`
    );
  }
}

// Draft would be a more adequate name, since it can transform to a Book later.
class Draft extends Book {
  // We've created a new property here to control the state.
  private isComplete: boolean = false;

  public setComplete(isComplete: boolean) {
    this.isComplete = isComplete;
  }

  // It will only return an error if explicitly set.
  public checkSales(): void {
    if (this.isComplete) super.checkSales();
  }
}

// Now, both cases work normally.

const book = new Book("The Time Machine", "H. G. Wells");
book.setSales(50000000);
book.checkSales();

const incompleteBook = new IncompleteBook("The Time Machine", "H. G. Wells");
incompleteBook.setComplete(true);
incompleteBook.setSales(50000000);
incompleteBook.checkSales();
```

---

## Technical example (Front-End)

For Front-End abstraction, let's imagine a **Button** entity that was extended to the subclass **DisabledButton**. If I substitute one for the other, what unexpected behaviors might I encounter?

**🔴 Incorrect Implementation**

```typescript
// Class for our button entity.
class Button {
  // We start with the button text.
  constructor(public label: string, public event: () => void) {}

  // We have the generic logic for the press event.
  public onPress() {
    console.log("The button was pressed! Executing event...");
    this.event();
  }
}

// However, a disabled button will not be able to execute the method correctly.
class DisabledButton extends Button {
  public onPress() {
    console.log("The button is disabled and cannot be pressed.");
  }
}

// When we instantiate the button as Button, we get the expected behavior.
const myButton = new Button("Click here", () => console.log("Clicked!"));
myButton.onPress();
// OUTPUT:
// Clicked!

// VIOLATION OF THE PRINCIPLE: If we substitute it with DisabledButton, the behavior changes.
// If this was not expected, the principle was violated. That is, to be characterized as a violation,
// it does not necessarily need to return an error, but it needs to exhibit an unexpected abnormal behavior.
const myButton2 = new DisabledButton("Click here", () => console.log("Clicked!"));
myButton2.onPress();
// OUTPUT:
// The button is disabled and cannot be pressed.
```

**🟢 Correct Implementation**

Here, personally, I would say that the ideal would be not to use a subclass called **DisabledButton**, but to transform its implementation into a **isDisabled** property within **Button**. Some questions may arise:

- **Doesn't this violate the Single Responsibility Principle?** In my point of view, no. Being enabled or disabled is still part of the context of a button.
- **How do I know when I should or shouldn't discard the subclass?** Of course, be careful with uncontrolled refactoring. Analyze carefully and assess the risks.

---

## Technical example (Back-End)



**🔴 Incorrect Implementation**

```typescript
// Here we have an ABSTRACT class for a database.
abstract class DatabaseConnection {
  abstract connect(): void;
  abstract query(query: string): void;
  abstract disconnect(): void;
}

// Then we can specify the CONCRETE implementation for each type of database below.

class MySQLConnection extends DatabaseConnection {
  connect(): void {
    console.log("Connecting to MySQL.");
    // Specific implementation for MySQL.
  }

  query(query: string): void {
    console.log(`Executing MySQL query: ${query}`);
    // Specific implementation for MySQL.
  }

  disconnect(): void {
    console.log("Disconnecting from MySQL.");
    // Specific implementation for MySQL.
  }
}

class MongoDBConnection extends DatabaseConnection {
  connect(): void {
    console.log("Connecting to MongoDB.");
    // Specific implementation for MongoDB.
  }

  // VIOLATION OF THE PRINCIPLE: No implementation was actually developed for this type of database.
  query(query: string): void {
    // No implementation was made.
  }

  disconnect(): void {
    console.log("Disconnecting from MongoDB.");
    // Specific implementation for MongoDB.
  }
}

// This will work.
const mysqlConnection = new MySQLConnection();
mysqlConnection.connect();
mysqlConnection.query('SELECT * FROM MY_TABLE');
mysqlConnection.disconnect();

// If we try to switch for MongoDB, it will fail.
const mongodbConnection = new MongoDBConnection();
mongodbConnection.connect();
mongodbConnection.query('SELECT * FROM MY_TABLE'); // Error: Cannot read property 'query' of undefined
mongodbConnection.disconnect(); // This will not even run.
```

**🟢 Correct Implementation**

The solution is simple: **the subclass must obey the limitations imposed by the superclass**. If the class is demanding the implementation of the `query` method, then it must be implemented.

---

## Personal example

In **Donkey Kong 64**, you can have multiple characters, each with their own attacks, special abilities, and even collectibles. However, what if I need a special attack, but one of the characters doesn't have it?

It's a very similar situation to the Back-End example, and it's all about **honoring the contract from the class you're extending from**.

**🔴 Incorrect Implementation**

```typescript
// Imagine we have a Kong class for each character.
abstract class Kong {
  abstract attack(): void;
  abstract specialAbility(): void;
}

class DonkeyKong extends Kong {
  public attack() {
    console.log('Donkey Kong is attacking!')
  }

  public specialAbility() {
    console.log('Donkey Kong is using a special ability!')
  }
}

class DiddyKong extends Kong {
  public attack() {
    console.log('Diddy Kong is attacking!')
  }

  // VIOLATION OF THE PRINCIPLE: This method was not implemented for Diddy Kong.
  // Now, imagine we switch characters in the middle of the game. The game
  // would have crashed because this method was not implemented.
  public specialAbility() {
    // No implementation was actually done.
  }
}
```

**🟢 Correct Implementation**

Bom, novamente, a solução é visualmente simples: **Diddy Kong** deve, obrigatoriamente, implementar os métodos propostos por **Kong**.

---

## Functional example

Let's keep our functional examples talking about **file reading**. Let's suppose we have an interface, a contract, for a **FileReader** for our application. Therefore, I can create multiple fileReaders, each for a distinct situation, as long as they fulfill our contract.

However, what if the concrete implementation of these interfaces is not properly done?

**🔴 Incorrect Implementation**

```typescript
// Here we have an interface that allows us to create
// how many custom File Readers we want.
type FileReaderFunction = (file: string) => { result: string };

// This one properly works.
const myFileReader: FileReaderFunction = (file) => {
  const fileContent = fileSystem.read(file);
  return { result: "Here's the content from the file: " + fileContent };
};

// VIOLATION OF THE PRINCIPLE: If you're going to implement an
// interface, you better honor what it proposes. Here,
// the file reader is not properly implemented.
const anotherFileReader: FileReaderFunction = (file) => {
  throw new Error("This was not implemented!");
};
```

**🟢 Correct Implementation**

You guessed it: **anotherFileReader** should adhere to the Liskov Substitution Principle by actually honoring and respecting the contract of **FileReaderFunction**.

---

## Applicabilities

The Liskov Substitution Principle is very interesting because it proposes a **consistent hierarchy** among the members of the same system and, in my opinion, suggests more reflective work than actual code refactoring. As Martin himself comments, issues with violating this principle are often identified too late, and the solution ends up being an **if-else**.

However, its applicability can be very well observed during the **design** phase. A developer responsible for implementing a new functionality by extending an existing class will start to consider how substitutable it would be, or if it would really be worth applying this extension.

---

## Final thoughts

Of all the principles I've discussed so far, I believe this one is among the most contextual. In my humble opinion, constantly "banging your head" to make this principle work isn't always the right solution - sometimes a simple unification of contexts makes much more sense.

In this article, I addressed the example of the **Book** entity, and whether it is complete or not could very well be part of the same entity; but for didactic purposes, I chose to refactor considering the principle in question. Regardless of the path taken, the best benefit from this principle is, undoubtedly, **the critical look at the extensions made**.