Introduction
SOLID is one of the most popular design principles in object-oriented software development. Adopting these practices can prevent code smells, refactoring code, and Agile or Adaptive software development. It was promoted by Robert C Martin and is used across the object-oriented design spectrum. It’s a mnemonic acronym for the following five design principles :
I’m going to try to explain SOLID Principles in the simplest way so that it’s easy for beginners to understand. Let’s go through each principle one by one :
1. Single Responsibility Principle :
“A module should have only one reason to change”
There should be no more than one reason to modify a class or a module. That means everything in the module should be related to that single purpose. It does not mean that your module/classes should only contain one method or property.
Why ?
- To make software easier to implement.
- To prevents unexpected side-effects of future changes.
Example :
In Scala, the Single Responsibility Principle applies to Functions, Data Structures, and Packages/Modules of functions.
2. Open Close Principles :
“A module should be open for extenstions but closed for modifications”
Why ?
- To avoid side effects.
- To minimize code-touch points.
Examples :
3. Liskov Substitution Principle :
“Subclass should be substitutable for their base classes”
A derived class is substitutable for its base class if:
- 1. Its preconditions are no stronger than the base class method.
- 2. Its postconditions are no weaker than the base class method.
Or, in other words, derived methods should expect no more and provide no less.
Why ?
- To avoid side effects.
Examples :
4. Interface Segregation Principle :
“Many specific interfaces are better than one general purpose interface”
In simple words, clients should not be forced to depend upon interface members they do not use. The Interface Segregation Principle guides us to create multiple, smaller, cohesive interfaces.
Why ?
- To increase reusability.
- To avoid side effects.
Examples :
5. Dependency Inversion Principle :
“Depend on abstractions, not on concretions”
Dependency inversion talks about the coupling between the different classes or modules. It focuses on the approach where the higher classes are not dependent on the lower classes but instead depend upon the abstraction of the lower classes. The main motto of the dependency inversion is Any higher classes should always depend upon the abstraction of the class rather than the detail.
Why ?
- To reduce the effort of adjusting to existing code changes.
- To avoid side effects.
- To increase reusability.
Examples :
Conclusion:
Implementing SOLID design principles during development will lead to systems that are more maintainable, scalable, testable, and reusable.
