[amazon_textlink asin=’1484227611|1484236394′ text=’SOLID Design Principles’ template=’ProductLink’ store=’desibanjara22-21|desibanjaraco-21′ marketplace=’IN|UK’ link_id=’c71be429-b44f-11e8-bcc2-e9178ccb09b7′] are the design principles that enable us developers to manage most of the software design problems. The term SOLID is an acronym for five design principles intended to make software designs more understandable, flexible and maintainable. The principles are a subset of many principles introduced by Robert C. Martin and SOLID acronym was first introduced by Michael Feathers. These principles help developers create and maintain a codebase that is strong but flexible to grow and change with minimal difficulty.
SOLID Acronym
S – Single Responsibility Principle (SRP)
O – Open Closed Principle (OSP)
L – Liskov Substitution Principle (LSP)
I – Interface Segregation Principle (ISP)
D – Dependency Inversion Principle (DIP)
Single Responsibility Principle
According to Single Responsibility Principle (SRP) “A class should have one, and only one, reason to change.”
Every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class.
Open/Closed Principle
“Software entities should be open for extension, but closed for modification”
Software design should be done in a way that new functionality could be added with minimum changes in the existing code. In other words, the design should be done in a way to allow the adding of new functionality as new classes and keeping existing code unchanged as much as possible
Liskov Substitution Principle
This principle is introduced by Barbara Liskov. According to this principle “objects in a program should be replaceable with instances of their sub-types without altering the correctness of that program”. In other words, Derived types must be substitutable for their base types.
If a program module is using a Base class, then the reference to the Base class can be replaced with a Derived class without affecting the functionality of the program module.
Interface Segregation Principle
“Many client-specific interfaces are better than one general-purpose interface.”
We should not enforce clients to implement interfaces that they don’t use. Instead of creating one big interface we can break down it to smaller interfaces
Dependency Inversion Principle
One should “depend upon abstractions, [not] concretions”. Abstractions should not depend on the details whereas the details should depend on abstractions.
High-level modules should not depend on low level modules.
[amazon_link asins=’1484227611,9048143268,1455778818,1509302581,1468489763,0123969840,B07B6R6WC9,1493926616,3319411586′ template=’ProductGrid’ store=’desibanjara22-21′ marketplace=’IN’ link_id=’711b2e58-b450-11e8-a2c9-21db0574c2c3′]