DEV Community

Cover image for Solid Principles in Javascript
Francesco Ciulla
Francesco Ciulla

Posted on • Updated on

Solid Principles in Javascript

The SOLID principles are a set of software design principles, that help us to understand how we can structure our code in order to be robust, maintainable, flexible as much as possible

Here come the S.O.L.I.D. principles:


S - Single Responsibility Principle

Alt Text

Any function must be responsible for doing only ONE thing.
Only one potential change in the software’s specification should be able to affect the specification of the class.

Example : Let's say we want to validate a form, then create a user in a DB

NO

/* A function with such a name is a symptom of ignoring the Single Responsibility Principle
*  Validation and Specific implementation of the user creation is strongly coupled.
*  That's not good
*/ 
validateAndCreatePostgresUser = (name, password, email) => {   

  //Call an external function to validate the user form
  const isFormValid = testForm(name, password, email); 

  //Form is Valid
  if(isFormValid){
    CreateUser(name, password, email) //Specific implementation of the user creation!
  }
}
Enter fullscreen mode Exit fullscreen mode

YES

//Only Validate
validateRequest = (req) => {

  //Call an external function to validate the user form
  const isFormValid = testForm(name, password, email); 

  //Form is Valid
  if(isFormValid){
    createUser(req); // implemented in another function/module 
  }
}

//Only Create User in the Database
createUser = (req) => CreateUser(req.name, req.password, req.email)

/*A further step is to declarel this function in another file
* and import it into this one.
*/
Enter fullscreen mode Exit fullscreen mode

This seems a pretty little change, but decouples the logic of validation from the user creation, which could change in the future, for many reasons!


O - Open-Closed Principle

Alt Text

Software systems must be allowed to change their behavior by adding new code rather than changing the existing code.

Open for extension, but Closed to modification

If we have something like this:

const roles = ["ADMIN", "USER"]
checkRole = (user) => {
  if(roles.includes(user.role)){
    return true; 
  }else{
    return false
  }
}

//Test role
checkRole("ADMIN"); //true
checkRole("Foo"); //false

Enter fullscreen mode Exit fullscreen mode

And we want to add a superuser, for any reason, instead of modifying the existing code (or maybe we just can't modify it), we could do it in another function.

//UNTOUCHABLE CODE!!!
const roles = ["ADMIN", "USER"]
checkRole = (user) => {
  if(roles.includes(user.role)){
    return true; 
  }else{
    return false
  }
}
//UNTOUCHABLE CODE!!!

//We can define a function to add a new role with this function
addRole(role){
  roles.push(role)
}

//Call the function with the new role to add to the existing ones
addRole("SUPERUSER");

//Test role
checkRole("ADMIN"); //true
checkRole("Foo"); //false
checkRole("SUPERUSER"); //true
Enter fullscreen mode Exit fullscreen mode


L - Liskov Substitution Principle

Alt Text

Build software systems from interchangeable parts.

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

class Job {
  constructor(customer) {
    this.customer = customer;
    this.calculateFee = function () {
      console.log("calculate price"); //Add price logic
    };
  }
  Simple(customer) {
    this.calculateFee(customer);
  }
  Pro(customer) {
    this.calculateFee(customer);
    console.log("Add pro services"); //additional functionalities
  }
}



const a = new Job("Francesco");
a.Simple(); 
//Output:
//calculate price


a.Pro();
//Output: 
//calculate price 
//Add pro services...
Enter fullscreen mode Exit fullscreen mode


I - Interface Segregation Principle

Alt Text

Many client-specific interfaces are better than one general-purpose interface.

We don't have interfaces in Javascript, but let's see this example

NO

//Validate in any case
class User {
  constructor(username, password) {
    this.username = username;
    this.password = password;
    this.initiateUser();
  }
  initiateUser() {
    this.username = this.username;
    this.validateUser()
  }

  validateUser = (user, pass) => {
    console.log("validating..."); //insert validation logic here!
  }
}
const user = new User("Francesco", "123456");
console.log(user);
// validating...
// User {
//   validateUser: [Function: validateUser],
//   username: 'Francesco',
//   password: '123456'
// }
Enter fullscreen mode Exit fullscreen mode

YES

//ISP: Validate only if it is necessary
class UserISP {
  constructor(username, password, validate) {
    this.username = username;
    this.password = password;
    this.validate = validate;

    if (validate) {
      this.initiateUser(username, password);
    } else {
      console.log("no validation required"); 
    }
  }

  initiateUser() {
    this.validateUser(this.username, this.password);
  }

  validateUser = (username, password) => {
    console.log("validating...");
  }
}

//User with validation required
console.log(new UserISP("Francesco", "123456", true));
// validating...
// UserISP {
//   validateUser: [Function: validateUser],
//   username: 'Francesco',
//   password: '123456',
//   validate: true
// }


//User with no validation required
console.log(new UserISP("guest", "guest", false));
// no validation required
// UserISP {
//   validateUser: [Function: validateUser],
//   username: 'guest',
//   password: 'guest',
//   validate: false
// }
Enter fullscreen mode Exit fullscreen mode


D - Dependency Inversion Principle

Alt Text

Abstractions must not depend on details.

Details must depend on abstractions.

NO

//The Http Request depends on the setState function, which is a detail
http.get("http://address/api/examples", (res) => {
 this.setState({
  key1: res.value1,
  key2: res.value2,
  key3: res.value3
 });
});
Enter fullscreen mode Exit fullscreen mode

YES

//Http request
const httpRequest = (url, setState) => {
 http.get(url, (res) => setState.setValues(res))
};

//State set in another function
const setState = {
 setValues: (res) => {
  this.setState({
    key1: res.value1,
    key2: res.value2,
    key3: res.value3
  })
 }
}

//Http request, state set in a different function
httpRequest("http://address/api/examples", setState);
Enter fullscreen mode Exit fullscreen mode

I would like to thank my friend Oleksii Trekhleb for the contribution to this article.

Oleksii is the original author of this legendary GitHub repository
https://github.com/trekhleb/javascript-algorithms


In Conclusion...

The main goal of the SOLID principles is that any software should tolerate change and should be easy to understand.

The S.O.L.I.D. principles can be very useful to write code:

  • Easy to understand
  • Where things are where they're supposed to be
  • Where classes do what they were intended to do
  • That can be easily adjusted and extended without bugs
  • That separates the abstraction from the implementation
  • That allows to easily swap implementation (Db, Api, frameworks, ...)
  • Easily testable

That's all. If you have any question, drop a comment below.

Francesco

Latest comments (11)

Collapse
 
paulosandsten profile image
Paulo Sandsten • Edited

When reading about the SRP, I see a conflict in how it is being described here versus how uncle Bob describes it in his book, "Clean Architecture"

"Of all the SOLID principles, the Single Responsibility Principle (SRP) might be the least well understood. That's likely because it has a particular inappropriate name. It is too easy for programmers to hear the name and then assume that it means that every module should do just one thing.

Make no mistake, there is a principle like that. A function should do one, and only one, thing. We use that principle when we are refactoring large functions into smaller functions; we use it at the lowest levels. But is is not one of the SOLID principles – it is not the SRP" - Uncle Bob

In the book mentioned, Uncle Bob defines it:
"A module should be responsible to one, and only one, actor"

With an actor, he mentions that it refers to one or more people who requires a change.

I really like that you are writing about SOLID and sharing. Thank you for that. I would like to hear more about your reasoning here regarding SRP.

Cheers.

Collapse
 
dimpiax profile image
Dmytro Pylypenko • Edited

Hey, in your example of S, good to see clear example of responsibilities conjunction, where you follow also D principle:

// process
validateRequest = (req) => isValidForm(req) && createUser(req)

//Call an external function to validate the user form
isValidForm = (req) => testForm(req.name, req.password, req.email)

//Only Create User in the Database
createUser = (req) => User.Create(req.name, req.password, req.email)

What is the purpose of example in I:

initiateUser() {
  this.username = this.username; // this?
  this.password = this.password; // this?
  this.validateUser(this.username, this.password);
}
Collapse
 
francescoxx profile image
Francesco Ciulla

Dear Dmytro,
Thank you for noticing, the example in "I" has been revised.
But the intent was to just show the purpose of the principle, not the concrete implementation, which is lacking of course! As the validation method is just loggining a string :)

Collapse
 
jochemstoel profile image
Jochem Stoel

Hey, this was nice to read. Good for my ego. Did you come up with this SOLID JavaScript or is this a common term on the web?

Collapse
 
kopseng profile image
Carl-Erik Kopseng • Edited

It's a 20 year old concept made popular by "Dr. Bob" (i.e. the agile programming disciple Robert Martin of "Clean Code" fame) that was very widely disseminated in the first decade of the so called "software craftsmanship" movement. en.wikipedia.org/wiki/SOLID

Collapse
 
francescoxx profile image
Francesco Ciulla

A fairly widespread concept. Thanks for the feedback

Collapse
 
jochemstoel profile image
Jochem Stoel

I had never heard of this SOLID thing but arrived at exactly the same conclusions and methods myself so that is always nice to discover.

Collapse
 
damxipo profile image
Damian Cipolat

Nice examples, but I think the "L" of lisvok is useless if you don't work in JS using OOP.

Collapse
 
francescoxx profile image
Francesco Ciulla

Thank you. The important part is to grasp the concept.

Collapse
 
freshi profile image
Wachirajob

Nice post with good examples.

Collapse
 
francescoxx profile image
Francesco Ciulla

Thank you