SOLID Principles in JavaScript (1): What "S" Stands for

You may already know some design principles or design patterns. This article mainly explains the SOLID principles gradually:

• How do you code without SOLID and what are the problems?
• Which principle in SOLID should be used?
• How should we modify the code using SOLID?

I believe that contrasting and immersive examples will make it easier for you to understand SOLID principles and how to apply them to code practice.

This is the first translated article of SOLID (there are five original articles), from hackernoon, the author is serhiirubets, welcome to continue to pay attention.

In this article, we will discuss what SOLID principles are, why we should use them and how to use them in JavaScript.

What is SOLID

SOLID is an acronym for Robert C. Martin's Top Five Object-Oriented Design Principles. The purpose of these principles is to make your code and architecture more readable, maintainable, and flexible.

Single Responsibility Principle

S - Single Responsibility Principle An entity should solve a specific task.

When our classes (functions, components, services) do a lot of things, we get a bunch of associated code, and if we change one place, it may affect other places, which are actually not relevant. And this class is difficult to maintain, and new code changes may affect other places and cause unpredictable problems. Readability will also be poor, and if the file has a large amount of code, it will be extremely painful to understand.

Let's first look at an example that does not use the single principle:

 class Movie {
  constructor(options){
    this.name = options.name;
    this.description = options.description;
    this.rating = options.rating;
  }
  changeDescription (newDescription) {
    this.description = newDescription;
  }
  changeRat ing (newRating) { 
    this.rating = newRating; 
  }
  saveUserToFile() []
  saveUserToDB() []
} 

We wrote a simple class Movie and provided a method to modify the description, rate, and save the movie to a database or file system. It doesn't seem to be a problem, but considering possible future extensions:

• We might add some new methods like: get data for a movie from the database, validate when the movie is saved, delete the movie from the database, etc. Our class will be the "God Object" anti-pattern (" God pattern": One class does too much, or puts a lot of unrelated logic into one class to do it).
• We may modify one method, which will affect other places with a high probability.
• Duplicate code. We might have other classes, like Audio or Picture, which might also use similar database, filesystem, and authentication methods, what should we do? The first idea might be to write the same method in every class (Audio, Picture, Movie), which happens to be the second anti-pattern "DRY" (Don't repeat yourself.). And if there are many classes in the system, and each class has its own method, when making adjustments, there is a high probability that you will forget to modify the logic of a certain class, which will cause problems.
• Harder to understand and maintain.

So how to rewrite the code logic to solve these problems? We should first remember to use the "Single Responsibility Principle", "Single Responsibility" is actually "one entity solving a specific task". So what are the tasks in the "Movie" class?

• Process movie data
• Operating the database
• Operating the file system

Then we can create 3 classes: Movie, DB, FileSystem.

 class Movie {
    constructor(options) {
        this.name = options.name ;
        this.description = options.description; 
        this.rating = options.rating;
    }
    changeDescription(newDescription) {
        this.description = newDescription;
    }
    changeRat ing (newRating) {
        this.rating = newRating;
    }
}

class DB {
    constructor(options) {
        this.url = options.url;
        this.loginname = options.loginname;
        this.password = options.password;
    }
    save(data) {}
    delete(id) {}
}

class FileSystem {
    constructor(options) {
        this.name = options.name;
    }
    save(data) {}
    delete(data) {}
}

Now we have 3 separate classes, each of which is only used to accomplish a specific task. This separation has the following benefits:

• DRY principle . We don't need to repeat the logic of DB (file), we can pass any entity (music, picture) to DB class and the class will save them to DB.
• The code is more readable and the logic is simpler.
• No "God Object"

Welcome to the WeChat public account "Chaos Front End"

Recommended reading:

Understanding SOLID principles of programming based on TypeScript

clean-code-javascript: SOLID