Why SOLID
Old-fashioned software development is dead. All most all the software development organization are trying to change their process and they see agile software development best possible solution for the time being. As developers we all know that we don’t have all the requirement at the front. Even if we have all the requirements at the front, requirement will changed during the project’s duration. So agile methodology provides the best solution for above problem.
The point of having SOLID code is to make code so supple that requirement changed we can easily change the code to fit the new requirements. So SOLID provides great help for agile development. It helps to write more flyable code.
Advantages of SOLID
If your code is difficult to adopt with new changes or code is every easily to break due to new changes then your code is not SOLID one. SOLID code can easily adopt with new changes and it is make you more productive by making code more maintainable. Basically SOLID provides solutions for following well known problems
Rigidity
Some time you may have experience that when you get a new requirement, it is very difficult to meet that requirement because of rigid design. This is called rigidity.
Fragility
Fragility mean it is every easy to break your code due to new requirement or anything else. If a developer who is not familiar with architecture get a task to working on code base, if it is fragility design then things start falling apart.
Immobility
Immobility means design is difficult to reuse. If your code difficult to reuse by others then your design is having problems
Viscosity
Viscosity means, design is difficult to do right things.
Over-design
When we are designing software system sometime design is having a needless complexity. This is very common problem most of code bases.
Overview
SOLID is acronym. The S stands for Single Responsibility principle which state that every class is having a single responsibility. The O stands for open closed principle which state that your design should be open for extension but closed for modification. The L stands for Liskov Substitution Principle which describes how polymorphism should work. The LSP states that object should be replaceable by instances of its sub-types without changing or correctness of the program. The I is stand for Interface Segregation principle which describes how interfaces should be designed. Finally the D is stand for Dependency Inversion Principle which state describes how abstraction and concretion should link. When we design class should be depend on the abstraction not on the concretion that is describe by DIP.
Single Responsibility Principle
The SRP tells us that a class should only have a single responsibility. We define a responsibility as a reason to change. So another way to put the SRP is to say that a class should have only one reason to change. Simply here our concern is really Separation of concerns. If a system is having lots of concerns, simply we can divides those concerns in to different classes.
