Making use of SOLID rules to TypeScript

Outlined way back, the SOLID rules are supposed to enhance the readability, adaptability, extensibility, and maintainability of object-oriented designs. The 5 SOLID rules of object-oriented class design facilitate the event of comprehensible, examined software program that many builders can use at any time and place.

We give Robert C. Martin, popularly often known as Uncle Bob, credit score for this concept in his 2000 work, Design Rules and Design Patterns. He’s additionally recognized for the best-selling books Clear Code and Clear Structure. The abbreviation SOLID was later coined by Michael Feathers for instance the concepts recognized by Uncle Bob.

On this article, we’ll go over every of the SOLID rules, offering TypeScript examples for instance and perceive them. Let’s get began!

S: Single-responsibility precept

In line with the single-responsibility precept, a category needs to be liable for just one exercise and solely have one trigger to alter. This rule additionally consists of modules and features.

Let’s think about the instance under:

class Pupil {
  public createStudentAccount(){
    // some logic
  }

  public calculateStudentGrade(){
    // some logic
  }

  public generateStudentData(){
    // some logic
  }
}

The concept of a single obligation is damaged within the Pupil class above. Consequently, we must always divide the Pupil class into totally different states of duty. In line with SOLID, the thought of duty is a purpose to alter.

To pinpoint a purpose to alter, we have to look into what our program’s tasks are. We’d change the Pupil class for 3 totally different causes:

• The createStudentAccount computation logic adjustments
• The logic for calculating pupil grades adjustments
• The format of producing and reporting pupil information adjustments

The one-responsibility precept highlights that the three elements above put three totally different tasks on the Pupil class:

class StudentAccount {
  public createStudentAccount(){
    // some logic
  }
}


class StudentGrade {
  public calculateStudentGrade(){
    // some logic
  }
}


class StudentData {
  public generateStudentData(){
    // some logic
  }
}

Now that we‘ve divided the courses, every has just one obligation, one duty, and just one alteration that must be made. Now, our code is less complicated to elucidate and comprehend.

O: Open-closed precept

In line with the open-closed precept, software program entities needs to be open for extension however closed for modification. The important idea behind this method is that we must always be capable to add new performance with out requiring adjustments to the prevailing code:

class Triangle {
  public base: quantity;
  public top: quantity;
  constructor(base: quantity, top: quantity) {
    this.base = base;
    this.top = top;
  }
}


class Rectangle {
  public width: quantity;
  public top: quantity;
  constructor(width: quantity, top: quantity) {
    this.width = width;
    this.top = top;
  }
}

Let’s think about that we need to develop a operate that calculates the world of a set of shapes. With our present design, it would seem one thing like the next:

operate computeAreasOfShapes(
  shapes: Array<Rectangle | Triangle>
) {
  return shapes.scale back(
    (computedArea, form) => {
      if (form instanceof Rectangle) {
        return computedArea + form.width * form.top;
      }
      if (form instanceof Triangle) {
        return computedArea + form.base * form.top * 0.5 ;
      }
    },
    0
  );
}

The issue with this technique is that each time we add a brand new form, now we have to alter our computeAreasOfShapes operate, thereby violating the open-closed idea. To exhibit this, let’s add one other form referred to as Circle:

class Circle {
  public radius: quantity;
  constructor(radius: quantity) {
    this.radius = radius;
  }
}

As towards the open-closed precept, the computeAreasOfShapes operate must change to a circle occasion:

operate computeAreasOfShapes(
  shapes: Array<Rectangle | Triangle | Circle>
) {
  return shapes.scale back(
    (calculatedArea, form) => {
      if (form instanceof Rectangle) {
        return computedArea + form.width * form.top;
      }
      if (form instanceof Triangle) {
        return computedArea + form.base * form.top * 0.5 ;
      }
      if (form instanceof Circle) {
        return computedArea + form.radius * Math.PI;
      }
    },
    0
  );
}

We will remedy this situation by imposing that every one of our shapes have a way that returns the world:

interface ShapeAreaInterface {
  getArea(): quantity;
}

Now, the shapes class must implement our outlined interface for ShapeArea to name its getArea() technique:

class Triangle implements ShapeAreaInterface {
  public base: quantity;
  public top: quantity;
  constructor(base: quantity, top: quantity) {
    this.base = base;
    this.top = top;
  }

  public getArea() {
    return this.base * this.top * 0.5
  }
}



class Rectangle implements ShapeAreaInterface {
  public width: quantity;
  public top: quantity;
  constructor(width: quantity, top: quantity) {
    this.width = width;
    this.top = top;
  }
  public getArea() {
    return this.width * this.top;
  }
}

Now that we’re sure that every one of our shapes have the getArea technique, we are able to put it to use additional. From our computeAreasOfShapes operate, let’s replace our code as follows:

operate computeAreasOfShapes(
  shapes: Form[]
) {
  return shapes.scale back(
    (computedArea, form) => {
      return computedArea + form.getArea();
    },
    0
  );
}

Now, we don’t have to alter our computeAreasOfShapes operate each time we add a brand new form. You’ll be able to take a look at this out with the Circle form class. We make it open for extension however closed for modification.

L: Liskov Substitution Precept

The Liskov substitution precept, put forth by Barbara Liskov, helps to make sure that modifying one side of our system doesn’t have an effect on different components negatively.

In line with the Liskov substitution precept, subclasses needs to be interchangeable with their base courses. This means that, assuming that class B is a subclass of sophistication A, we must always be capable to current an object of sophistication B to any technique that expects an object of sort A with out worrying that the tactic could produce unusual outcomes.

To make it clearer, we‘ll dissect this concept into totally different elements. Let’s use the instance of a rectangle and sq.:

class Rectangle {
    public setWidth(width) {
        this.width = width;
    }
    public setHeight(top) {
        this.top = top;
    }
    public getArea() {
        return this.width * this.top;
    }
}

Now we have a simple Rectangle class, and the getArea operate returns the rectangle’s space.

Now, we’ll select to make one other class particularly for squares. As you could nicely know, a sq. is solely a specific number of rectangle wherein the width and top are equal:

class Sq. extends Rectangle {

    setWidth(width) {
        this.width = width;
        this.top = width;
    }

    setHeight(top) {
        this.width = top;
        this.top = top;
    }
}

The code above runs with out errors, as proven under:

let rectangle = new Rectangle();
rectangle.setWidth(100);
rectangle.setHeight(50);
console.log(rectangle.getArea()); // 5000

However, we’ll run into issues once we swap out a father or mother class occasion for one among its youngster courses:

let sq. = new Sq.();
sq..setWidth(100);
sq..setHeight(50);

Provided that setWidth(100) is predicted to set each the width and top to 100, you need to have 10,000. Nonetheless, this may return 2500 because of the setHeight(50), breaking the Liskov Substitution Precept.

To treatment this, you need to create a normal class for all shapes that comprises all the generic strategies you need the objects of your subclasses to have the ability to entry. Then, you’ll make a particular class for every distinctive technique, like a rectangle or sq..

I: Interface segregation precept

The interface segregation precept encourages smaller, extra focused interfaces. In line with this idea, a number of client-specific interfaces are preferable to a single general-purpose interface.

To see how simple it’s to know and use this straightforward principle, let’s think about the next situation:

interface ShapeInterface {
    calculateArea();
    calculateVolume();
}

The entire strategies should be outlined when a category implements this interface, even when you received’t use them, or in the event that they don’t apply to that class:

class Sq. implements ShapeInterface {
    calculateArea(){
        // some logic
    }
    calculateVolume(){
        // some logic
    }  
}

class Cylinder implements ShapeInterface {
    calculateArea(){
        // some logic
    }
    calculateVolume(){
        // some logic
    }    
}

From the instance above, you’ll see that you simply can not decide the quantity of a sq. or rectangle. You have to declare each technique, even those you received’t use or want as a result of the category implements the interface.

As a substitute, we would put in place extra compact interfaces, typically often known as function interfaces:

interface AreaInterface {
    calculateArea();
}


interface VolumeInterface {
    calculateVolume();
}

We will forestall bloating interfaces and simplify program upkeep by altering the way in which we take into consideration interfaces:

class Sq. implements AreaInterface {
    calculateArea(){
        // some logic
    }
}

class Cylinder implements AreaInterface, VolumeInterface {
    calculateArea(){
        // some logic
    }
    calculateVolume(){
        // some logic
    }    
}

D: Dependency inversion precept

In line with the dependency inversion idea, high-level modules shouldn’t be depending on low-level modules. As a substitute, each ought to depend on abstractions.

Uncle Bob sums up this rule as follows in his 2000 article, Design Rules and Design Patterns:

“If the open-closed precept (OCP) states the objective of object oriented (OO) structure, the DIP states the first mechanism”.

Merely mentioned, each high-level and low-level modules will rely on abstractions slightly than high-level modules depending on low-level modules. Each dependency within the design needs to be directed towards an summary class or interface. No dependency ought to goal a concrete class.

Let’s assemble an illustration to additional discover this precept. Take into account an order service. On this instance, we’ll use the OrderService class, which data orders in a database. The low degree class MySQLDatabase serves as a direct dependency for the OrderService class.

On this case, we’ve violated the dependency inversion precept. Sooner or later, if we had been to change the database that we’re using, we’d want to change the OrderService class:

class OrderService {
  database: MySQLDatabase;

  public create(order: Order): void {
    this.database.create(order)
  }

  public replace(order: Order): void {
    this.database.replace
  }
}


class MySQLDatabase {
  public create(order: Order) {
    // create and insert to database
  }

  public replace(order: Order) {
    // replace database
  }
}

By designing an interface and making the OrderService class depending on it, we are able to enhance on this case by reversing the dependency. Now, slightly than counting on a low-level class, the high-level class relies on an abstraction.

We create an interface that helps summary our providers as follows:

interface Database {
  create(order: Order): void;
  replace(order: Order): void;
}


class OrderService {
  database: Database;

  public create(order: Order): void {
    this.database.create(order);
  }

  public replace(order: Order): void {
    this.database.replace(order);
  }
}


class MySQLDatabase implements Database {
  public create(order: Order) {
    // create and insert to database
  }

  public replace(order: Order) {
    // replace database
  }
}

Now, with out altering the OrderService class, we are able to add and prolong new databases providers.

Conclusion

On this article, we’ve explored each SOLID precept with sensible examples utilizing TypeScript. The SOLID rules enable us to enhance the readability and maintainability of our code, they usually additionally make it easier to extend our codebase with out compromising different areas of our utility.

When writing code, you need to preserve these tips in thoughts. You should definitely perceive what they imply, what they do, and why you want them along with object oriented programming (OOP). Joyful coding!