Thoughts about SOLID - The Letter "L"

// 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.

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();

// 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.

// 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.

// 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.
  }
}

// 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!");
};