Who said SOLID is applicable only in OO languages? Here's how you can do it in Javascript!

SOLID is five design principles intended to make software designs more understandable, flexible, and maintainable. It helps us to think about the right way to build a software system SOLID principles in Javascript SOLID is just a set of design principles that all coders and developers should follow to achieve a good design in the software they build. None other than proposed it. SOLID principles explain how to arrange our functions and data structures and how they can be interconnected. Robert C Martin The main goal of the SOLID principles is that any software should tolerate change and should be easy to understand. If we desire to build quality software, the SOLID principle is essential to be followed. Most people assume SOLID is only for strongly typed languages or object-oriented languages like JAVA and more. Though Javascript is a loosely typed language, we can easily apply SOLID principles on Javascript code. Let’s see how we can do that in this article. What does SOLID stand for? S — The Single Responsibility Principle Any software module in an organization should have one and only one reason to change. It means that any function should be responsible for doing only one thing. For instance, in react we can relate it to the stateless functional component. Let’s see it with an example. { re = ; isEmailValid = re.test(email); (isEmailValid){ createUserInDabase(name, email) } } ( ) function createUser name, email let /^([\w-]+(?:\.[\w-]+)*)@((?:[\w-]+\.)*\w[\w-]{0,66})\.([a-z]{2,6}(?:\.[a-z]{2})?)$/i let if In the above example what if the logic for the email changes. The function createUser should have only one reason to change. In our case only if the logic to create User Changes the function should change. So let’s see how we can change that to SRP { re = ; isEmailValid = re.test(req.email); (isEmailValid){ createUser(req.name, req.email) } } { createUserInDabase(name, email) } ( ) function validateRequest req let /^([\w-]+(?:\.[\w-]+)*)@((?:[\w-]+\.)*\w[\w-]{0,66})\.([a-z]{2,6}(?:\.[a-z]{2})?)$/i let if ( ) function createUser name, email O — The Open-Closed Principle Any software system should be open for extension and closed for change. This means that the software systems should be allowed to change their behavior by adding new code rather than changing the existing code. Let’s see an example for the Open-Closed Principle allowedRoles = [ , ] { (allowedRoles.includes(user.role)){ ; } { } } let "admin" "owner" ( ) function checkPrivilege user if return true //user has privilege else return false Now, what if the software system introduces a new role called and users with roles should also be granted privilege. So here we have to modify existing code to add guestAdmin to the list. So rather we can do like the below example to make it pass the Open-Closed principle. guestAdmin guestAdmin allowedRoles = [ , ] { (allowedRoles.includes(user.role)){ ; } { } } addRoles(role){ allowedRoles.push(role) } let "admin" "owner" ( ) function checkPrivilege user if return true //user has privilege else return false So here we don’t have to modify the existing code rather we can extend it to add a new role L — The Liskov Substitution Principle As per the LSP, . In simple words, derived classes must be substitutable for the base class. Let’s see the Liskov Substitution Principle with an example: functions that use references to base classes must be able to use objects of the derived class without knowing it License = { .calculateFee = { } } License.prototype.PersonalLicense = { .calculateFee(user) } License.prototype.BusinessLicense = { .calculateFee(user) .getUsers = { } } var ( ) function user this ( ) function //Logic to calculate Fee ( ) function user this ( ) function user this this ( ) function //Logic to get all users in Business The above example is perfectly in LSP because even if we replace the extended function PersonalLicense instead of License function. So to conclude LSP states that: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T. I — The Interface Segregation Principle Interface Segregation Principles advises avoiding depending on modules or functions or anything that they don’t use. But we don’t have an interface by default in Javascript. But we all would have faced situations where we want to do so many things on the constructor of a class. Let’s say some settings we have to do in the constructor. The settings we do should be segregated from the other unwanted settings in the constructor. For example: { (user){ .user = user; .initiateUser(); } initiateUser(){ .name = .user.name .validateUser() } } user = User({userProperties, validateUser(){}}); class User constructor this this this this this const new Here, validateUser() function will get invoked in initiateUser constructor call even though it’s not needed all the time. Here comes the Interface Segregation Principle. We can bring this into ISP with the below code: { (user){ .user = user; .initiateUser(); .setupOptions = user.options } initiateUser(){ .name = .user.name .setupOptions() } } user = User({userProperties, : {validateUser()}{}}); class User constructor this this this this this this const new options Here, we pass in options and only if we pass in options it will validate the User. So we are segregating the unwanted logic from the contractor. D — The Dependency Inversion Principle Dependency Inversion Principle states that high-level functions should not be dependant on the code that implements low-level functions. This principle tells us that the most flexible systems are those in which source code dependencies refer only to abstractions, not to concretions. In a statically typed language, like Java, this means that the use, import, and include statements should refer only to source modules containing interfaces, abstract classes. In case of Javascript we can see the below example: axios.get( , { .setState({ : response.value1, : response.value2 }); }); "/someAddress/someResource" ( ) function response this value1 value2 The above code is not in DIP. Let’s make it in DIP in the below example: requestWithAxios( , setResponseInState); { axios.get( , { setResponseInState.setValues(response); }); } setResponseInState ={ : { .setState({ : response.value1, : response.value2 }) } } "/someAddress/someResource" ( ) function requestWithAxios address, setResponseInState "/someAddress/someResource" ( ) function response var setValues ( ) function response this value1 value2 I hope this gave you a basic understanding of how to apply SOLID principles in Javascript. Applying SOLID principles can make the code cleaner, extensible and easier to understand. Thanks for reading this article. I head Tech at We are excited about building tools for modern leaders to help them put their people at the heart of business success. If you think you benefited from this blog, please share it with your friends and co-workers! In case you have any queries, clarification, or an idea for my next blog, please let me know in the comments! Upshotly.