SOLID Principles Explained
What are SOLID principles, and why do professionals use them? Their main aim is well to make your software solid. They make your code cleaner, more maintainable and scalable.
Many modern architectural patterns are based on them, so you will quickly understand them after reading this article.
S — Single Responsibility Principle
Every file (class or function) is responsible to a single actor. It’s easy to create false-positive code when breaking this rule. For example:
Let’s have a system where Participants play a game, and based on how many hours they played, they have to pay for it. Here in the Participant class, there are 3 functions calculateHours based on info from the Analyst, calculatePrice based on info from the Business Specialist, and save made by the DB Administrator.
calculatePrice uses calculateHours to multiply hourly prices times the time spent playing. One day, an Analyst decides to change how he calculates hours spent playing, and a programmer does that. Everything works and is accepted by the Analyst.
The business is losing money because calculatingPrice is depended on calculateHours and was based on the time spent. No one will be happy when someone finally finds out what is happening. Small mistakes like this could make the business go bankrupt.
Get Michal Ankiersztajn’s stories in your inbox
Join Medium for free to get updates from this writer.
We’ve all heard about these mistakes. They appear when we merge functionalities dependent on different actors.
O — Open-Closed Principle
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification — Bertrand Meyer
It means that the software should allow extension without modifying the existing codebase. It’s one of the most important principles when designing an Architecture.
Let’s say we have an app that shows your Medical Data. Now, your project manager tells you that a new function is required to export the data to a CSV file. If you follow the Open-Closed Principle, no changes are needed in the existing system. All you’ll have to do is extend it by adding a part responsible for creating CSV files. As you can see in the above diagram, we had to extend our software by adding CSVViewModel and CSV View.
L — Liskov Substitution Principle
If S is a subtype of T, then objects of type T may be replaced with objects of type S, without breaking the program — Barbara Liskov
LSP (Liskov Substitution Principle) — might be hard to understand when read at first, but a couple of examples should make it clear:
Here, MovieApp depends on Movie and uses the LSP correctly because the behaviour of MovieApp won’t change depending on what subtype we’ll use.
Here, FiguresApp depends on Rectangle, whose subtype is Square. It might feel intuitive. After all, a Square is a Rectangle, but there are problems since a Square must have identical width and height while a Rectangle does not. When using a Rectangle of the Square type, we can set different widths and heights, which will result in a crash. It violates LSP because the behaviour changes when using different types.
I — Interface Segregation Principle
ISP (Interface Segregation Principle) — depend on as little as possible.
Imagine that User1 uses operation op1, User2 uses op2, and User3 uses op3. In that situation, User1 will depend on op2 and op3 even though it doesn’t use them, and the program will have to recompile. We can fix it by introducing interfaces:
Here, each User depends on an interface with the operation they’re interested in instead of OPS with all of them. This way, each User class is independent from operations created for different User classes.
D — Dependency Inversion Principle
DIP (Dependency Inversion Principle) — says that the most flexible systems depend on abstractions instead of concrete elements. It would be ideal to depend on Interfaces and Abstract Classes only.
Abstraction is more flexible than concrete implementation. Changing abstraction forces concrete to change, but changing implementation doesn’t change abstraction.
However, it’s not entirely possible to not depend on any concrete classes. It’s okay to depend on stable and concrete classes such as String. It’s essential to depend on abstractions where concrete classes are likely to change.
Thanks for reading my article. I hope you’ve learned something new and become a better programmer! If you’ve liked the article, please give me a 👏
Based on books by the creator of SOLID:
Clean Architecture — Robert C. Martin
Clean Code — Robert C. Martin
Stackademic
Thank you for reading until the end. Before you go:
