![\"SpongBob](\"https://media.giphy.com/media/3o7aCTPPm4OHfRLSH6/giphy.gif\")
\n\nRepost of https://dev.to/rhuzaifa/solid-is-it-still-useful-in-2021-5ff6
\n
In the software development world, there are 2 extremes.
\n
If you are lazy like me you mostly don’t follow best-practices because YAGNI(You aren’t gonna need it) but if you are like me you mostly do follow best-practices like SOLID Design Principles.
\nWait. Why am I on both sides? Because I follow both depending on what I am doing. If it’s simple, limited/scoped, and predictable then who needs to overthink about best practices but if it’s complex, may-become-complex, should be scalable and maintainable then yeah, we need best practices.
\nIf you are building a system that would need changes in the future then you are going to be happy about how SOLID can make your life easy.
\nSOLID is an acronym for 5 principles
\nThey aim to make your code manageable, maintainable, and scalable along with other benefits.
\nThey are not Rules, but best practices.
\nThis was in the year 2000. Robert C. Martin first introduced SOLID as a subset of different design principles in his paper Design Principles and Design Patterns.
\nDesign principles and patterns are different, SOLID are principles.
\nEach SOLID principle aims to achieve a certain goal by following a certain rule.
\nIt aims to separate behaviors or concerns. Meaning that every piece of code should have a specific purpose of existence and it should be used for that purpose only.
\nThe following function should only validate a user given their id.
\nfunction validateUser(userId){\n // will validate user with their userId\n}For a complete reference, check out the Single Responsibility Principle in detail.
\nThe goal is to prevent those situations in which changing a piece of code from a module also requires us to update all depending modules. Basically, we don’t allow new code to make changes to our old code.
\nWe can extend code but not modify it. One real-life use case is of those softwares that have backward compatibility.
\nA typescript example
\ninterface PaymentMethod {\n pay() : boolean\n}\n\nclass Cash implements PaymentMethod {\n public pay(){\n // handle cash pay logic here\n }\n}\n\nfunction makePayment(payMethod: PaymentMethod) {\n if(payMethod.pay()){\n return true;\n }\n return false;\n}In the above code if we want to add credit card payment all we have to do is add the following code (along with the actual implementation) and it will work just fine
\nclass CreditCard implements PaymentMethod {\n public pay(){\n // handle credit pay logic here\n }\n}For a complete reference, check out my other article on Open/Close Principle.
\nWhat this principle tells us is that if we replace an instance of a child class with a parent class, our code should still work fine without breaking or having side effects.
\nclass Printer{\n function changeSettings(){\n // common functionality\n }\n\n function print(){\n // common functionality\n }\n}\n\nclass LaserPrinter extends Printer{\n function changeSettings(){\n // ... Laser Printer specific code\n }\n\n function print(){\n // ... Laser Printer specific code\n }\n}\n\nclass _3DPrinter extends Printer{\n function changeSettings(){\n // ... 3D printer specific code\n }\n\n function print(){\n // ... 3D printer specific code\n }\n}This principle however has its limitations some of which I discussed in its own separate article. See Liskov Substitution Principle for an example of its limitations.
\nThis principle aim’s to use role interfaces (or role modules in general) which are designed for a specific purpose and should only be used for those. It says
\n\n\nClients Should Not Be Forced To Depend Upon Interfaces That They Do Not Use.
\n
This principle solves some of the issues with the Interface Segregation Principle like the Bird example I mentioned in my article on Liskov Substitution Principle
\nThis is a typescript example but still not too difficult to understand.
\ninterface BirdFly{\n fly(): void;\n}\n\ninterface BirdWalk{\n walk(): void;\n}\n\nclass Duck implement BirdFly, BirdWalk{\n fly(){\n // Duck can fly\n } \n walk(){\n // Duck can walk\n }\n}\n\nclass Ostrich implement BirdWalk{\n walk(){\n // Ostrich can walk\n }\n} For a complete reference, check out the Interface Segregation Principle in detail.
\nIt focuses on using abstraction or facade/wrapper patterns to hide details of low-level modules from their high-level implementation.
\nWe basically create wrapper classes that sit in between high-level and low-level modules. This helps a lot if the low-level implementations are different from each other.
\nAgain a typescript example
\ninterface Payment {\n pay(): boolean\n}\n\n// (Wrapper/Abstraction around cash payment)\nclass CashHandler implements Payment {\n constructor(user){\n this.user = user\n this.CashPayment = new CashPayment();\n }\n\n pay(amount){\n this.CashPayment.pay(amount)\n }\n}\n\n// (low-level module)\nclass CashPayment {\n public pay(amount){\n // handle cash payment logic\n }\n}\n\n// (High-level Module)\nfunction makePayment(amount: number, paymentMethod: Payment){\n if(paymentMethod.pay(amount)){\n return true;\n }\n return false;\n}For a complete reference, check out the Dependency Inversion Principle in detail.
\nNow that we know a brief about each principle, we will look at when to use and avoid them.
\n| \n | Use | \nAvoid | \n
|---|---|---|
| Single Responsibility | \nFor Scalable and Maintainable Code. | \nWhen too much Fragmentation occurs without predictable future changes. | \n
| Open Close | \nTo prevent old code from breaking due to a new one. | \nWhen over-engineering. | \n
| Liskov Substitution | \nParent/Child used interchangeably without breaking. | \nWhen substitutions do not make sense. (Bird example) | \n
| Interface Segregation | \nFor Role-specific interfaces. | \nWhen difficult to aggregate (due to a lot of modules) from segregation. | \n
| Dependency Inversion | \nFor different low-level implementations. | \nWhen different implementations of a low-level module are not needed, like the String class in most languages are not changed because it’s not needed to mostly. | \n
Ask yourself. Is there a language that does everything with one line of code?
\ndo_everything();I guess not, unless you or someone makes a language that uses less code than python and does everything with one line of code, you do need SOLID design principles.
\nOf course, there are extremes and cases where it’s just not possible to implement SOLID, but if you are comfortable and can use SOLID then you probably should.
\nSo, what’s your take on this? Do you follow an approach similar to mine? Be sure to give this article a 💖 if you like it.
","frontmatter":{"title":"Solid. Is It Still Useful In 2021?","date":"April 04, 2021","description":"Explore the relevance of SOLID principles in modern software development. From fostering maintainable and scalable code to navigating real-world examples, this article delves into the practical applications and significance of SOLID design principles in today's coding landscape."}}},"pageContext":{"slug":"/blog/solid-is-it-still-useful-in-2021/","previous":{"fields":{"slug":"/blog/why-the-dependency-inversion-principle-is-worth-using/"},"frontmatter":{"title":"Why The Dependency Inversion Principle Is Worth Using"}},"next":{"fields":{"slug":"/blog/regex-the-minimum-you-need-to-know/"},"frontmatter":{"title":"Regex? The Minimum You Need To Know."}}}},"staticQueryHashes":["2276319502"]}