Single-responsibility : Every class/module should have a single purpose or responsibility.
- Avoid spaghetti code
- Allows you to implement proper separation of concerns
- Maintainability
Open-closed : Open for extension, closed for modification
- Changing requirements does not necessarily mean changing code
- Well-defined API’s
- Reusable code
Liskov substitution : Behavorial class substitution. If type A is derived from type B then you should be able to substitute objects of type B for objects of type A.
- Flexibility
- Well-defined abstractions
- Reusable code
Interface segregation : Favor multiple, specific interfaces over a single big interface
- Possible reduction in compile time
- Maintainability
- Proper separation of concerns
Dependency inversion : Depend on abstractions not implementations. High-level modules should not depend on low-level modules directly. They should both depend upon an abstraction.
- Loose coupling of software
- Huge benfit to code reusability
- Proper separation of concerns
Why SOLID?
- More extensible code
- Easier to maintain code
- Reusable code
