Welcome to the series "Clean Code"; brought to you by "Coding Mantis"!
"Even bad code can function. But if code isn't clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn't have to be that way." — Robert C. Martin
Much like pillars, there are certain principles on which software development relies. In this post, we'll examine the five most fundamental ones that come together and form the SOLID principles — insert Voltron joke.
What is SOLID?
SOLID is an acronym of acronyms, a cheat code if you will, to help us remember what it's about. Let's see what it stands for:
- S => SRP => Single Responsibility Principle
- O => OCP => Open/Closed Principle
- L => LSP => Liskov Substitution Principle
- I => ISP => Interface Segregation Principle
- D => DIP => Dependency Inversion Principle
SRP (Single Responsibility Principle)
As stated in SRP, every class, method, module, service, etc. should have a single clearly defined responsibility and, in the words of Robert C. Martin, it should have one and only one reason to change.
"Gather together the things that change for the same reasons. Separate things that change for different reasons." — Robert C. Martin
To put in simple everyday terms, the kitchen and the bathroom are two rooms of the house that have clear and defined responsibilities; you don't bathe in the kitchen or cook in the bathroom, and if you do, well, you might have to get some things in order.
The benefit of SRP is that it helps make the code more organized, readable, and reusable.
OCP (Open/Closed Principle)
The OCP suggests, to paraphrase Bertrand Meyer, that software entities should be Open for extension but Closed for modification.
It's not uncommon for a new requirement to arrive sooner or later and implementing it should not force us to make changes to existing code fragments that are functional and tested as this would introduce a risk of making a breaking change. There is a great paper with examples that you can find here.
LSP (Liskov Substitution Principle)
Introduced by Barbara Liskov in 1988, LSP suggests that each derived (child) class should be substitutable for their base (parent) classes without altering the correctness of the program. Taking a step deeper, we understand that LSP is complimentary to OCP and DIP since it allows us to interchange sibling implementations in runtime, effectively extending the behaviour, without the need to change our existing code.
"If it looks like a duck, quacks like a duck, but needs batteries - you have the wrong abstraction."
A classic example of the violation of the Liskov Substitution Principle is the Rectangle - Square problem.
ISP (Interface Segregation Principle)
Probably being the simplest principle to explain, the ISP states that a client should never be forced to depend on something that it doesn't utilize. It's also easily achievable by having small and specific interfaces that enable clients to choose which to implement based on the functionality they need.
DIP (Dependency Inversion Principle)
Complimentary to the LSP, the DIP attempts to avoid tight coupling between software modules by stating that high-level modules should not depend on low-level modules but merely on their abstractions.
Programming to a supertype enables us to decouple behaviour and implementation, effectively making the implementation interchangeable on runtime without affecting the module itself. An interesting example can be found here.
Conclusion
Though some people believe that SOLID is dated and/or solely related to OOP (Object-Oriented Programming), it is in fact applicable to more cases and it enables our minds to think of the approach we'll take for the solution we're delivering right from the beginning.
Clean, maintainable, and scalable code is not a matter of opinion or perspective; it's our duty as software engineers to deliver solutions that fit the above criteria, and for me, it's one of the things that separate the good from the tolerable in this profession.
"If the years have taught us anything it is that simplicity requires disciplines guided by principles. It is those principles that define simplicity. It is those disciplines that constrain the programmers to produce code that leans towards simplicity. The best way to make a complicated mess is to tell everyone to 'just be simple' and give them no further guidance." — Solid Relevance by Robert C. Martin
Do you follow SOLID when coding?