SOLID principles to make your code robust, maintainable & flexible.
SOLID principles were developed to combat problematic design patterns. The broad goal of the SOLID principles is to reduce dependencies so that engineers change one area of software without impacting others. SOLID principles help to make your code robust, maintainable, and flexible.
Here comes the S.O.L.I.D:
- Single Responsibility Principle (SRP)
- Open/Closed Principle (OCP)
- Liskov Substitution Principle (LSP)
- Interface Segregation Principle (ISP)
- Dependency Inversion Principle (DIP)
Let’s discuss some bad and good practices of these principles.
Single Responsibility Principle (SRP)
The idea behind the single responsibility principle is that all the classes, modules, functions, and anything inside your code must be a single part. One single responsibility is the core concept here. Always break down the responsibility of your code and make separate modules for individual responsibility.
- Each section of code has one single reason to change.
- Easier to follow the code
- Easier to read
- Smaller function
- More maintainable
Here are bad and good practices of the single responsibility principle. Please have a look.
Open/Closed Principle (OCP)
The core concept of the open/closed principle is you should always allow users to add new functionality in your codebase without changing the existing code. The open/closed principle prevents introducing new bugs in existing code.
- Open for extension, but closed for modification
- Don’t change existing code or classes
- Add new functionality with new modules or by reusing the existing code through delegation.
“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”
— by Bertrand Meyer
Liskov Substitution Principle (LSP)
Suppose you have a parent class and a child class, then the base class and child class can be used interchangeably without any unwanted result. The Liskov Substitution Principle is one of the most confusing so let’s have a look at the example below.
“If S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may substitute objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.).”
- Reduced coupling
- Easier maintenance
Interface Segregation Principle (ISP)
The whole idea of the Interface Segregation Principle is about segregating your interfaces and make them smaller.
“Clients shouldn’t be forced to depend on interfaces that they don’t use.”
Here are some good and bad practices that might be helpful to understand better.
- High cohesion — better understandability, robustness
- Low coupling — better maintainability, high resistance to changes
Dependency Inversion Principle (DIP)
High-level modules should not depend on low-level modules. This is the core concept of the Dependency Inversion Principle. Both modules should depend on abstraction in this principle.
- Helps to decouple the important things from the details
- Protects from a ripple effect from changes inside low-level modules
- Enables frequent changes
Have a great day!