# SOLID Principles in JavaScript The SOLID principles are software design principles that help us understand how we can structure our code to be robust, maintainable, and flexible as much as possible. ## Here come the **S.O.L.I.D.** principles: * **S**: [Single Responsibility](#s) * **O**: [Open/Close](#o) * **L**: [Liskov Substitution](#l) * **I**: [Interface Segregation](#i) * **D**: [Dependency Inversion](#d) --- ## S - Single Responsibility Principle ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ncarh7p96cma7dqavmry.jpg align="left") 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** ```javascript /* 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! } } ``` **YES** ```javascript //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. */ ``` 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](https://dev-to-uploads.s3.amazonaws.com/i/7rkq5we8s4ejtvfwjjeb.jpg align="left") 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: ```javascript const roles = ["ADMIN", "USER"] checkRole = (user) => { if(roles.includes(user.role)){ return true; }else{ return false } } //Test role checkRole("ADMIN"); //true checkRole("Foo"); //false ``` If we want to add a superuser, and for any reason, instead of modifying the existing code (or maybe we can't change it), we could do it in another function. ```javascript //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 ``` --- ## L - Liskov Substitution Principle ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/rxoc80g8jvkzhxah7yay.jpg align="left") 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. ```javascript 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... ``` --- ## I - Interface Segregation Principle ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ifbylnu5ed9uv5eaakeo.jpg align="left") 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** ```javascript //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' // } ``` **YES** ```javascript //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 // } ``` --- ## D - Dependency Inversion Principle ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/e7tbwj1inll7rvcipq7o.jpg align="left") Abstractions must not depend on details. Details must depend on abstractions. **NO** ```javascript //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 }); }); ``` **YES** ```javascript //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); ``` I want to thank my friend **Oleksii Trekhleb** for their 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 be easy to understand. ## The S.O.L.I.D. principles can be beneficial in writing 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 questions, drop a comment below. [Francesco](https://francescociulla.com)