SOLID Principle in Software Development.
Change is the only constant thing in this world. Just like seasons, life and people changes too. You get things the way you like it and then something beyond your authority bumps you off. Same goes with our development.
To Sustain in this changing environment you need to build a clean, reusable,maintainable and testable code. SOLID principle provides the same.
SOLID is a mnemonic acronym for five design principles intended to make software designs and define the five basic object-oriented design principles:
1. Single Responsibility Principle
2. Open-Closed Principle
3. Liskov Substitution Principle
4. Interface Segregation Principle
5. Dependency Inversion Principle
#1.Single Responsibility Principle
The Single responsibility principle is a computer programming principle that states that “every module, class, or function should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class”.
Robert C. Martin expresses the principle as, “A class should have only one reason to change.”
Example, we have an application which uses REST API’s for communication. So we have one class which consist of the API and all other modules use the same class to communicate. Further when the Base URL changes, we have to change in only one class.
#2.Open-Closed Principle
The Open-Closed principle states that “every module, class, or function must be open for extension,but closed for modification”.
Example, We have a Class Car which has a functionalities of a Car. We have to allow other classes to extent the base class Car to create sub-classes of that class but we must not allow the derived class to modify the base class i.e Car. To achieve this, we must declare the methods in the base class private to avoid modification in the same.
#3. Liskov Substitution Principle
The Liskov Substitution Principle (LSP) : “Functions that use pointers to base classes must be able to use objects of derived classes without knowing it”.
Means every subclass should be the substitution to its parent class without altering the correctness of that parent class.
In the above example, class BMW has extended class Car. So BMW is a car and its should extend all the functionalities of the Car. Now if we override the method accelerate , we should write the code only to accelerate otherwise it will cause problem to other classes extending the base class ‘Car’ because they are expecting the same behavior of acceleration.
#4. Interface Segregation Principle
Interface Segregation Principle states that “no client should be forced to depend on methods it does not use”.
Interface Segregation Principle splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces. ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy.
In the above example , it consist of lot of methods in one interface which is not required in the classes who are implementing it. Therefore, we should create separate interfaces for required methods instead of one.
#5. Dependency Inversion Principle
Dependency Inversion Principle states that “Entities must be dependent on abstractions and not on concretions”.
It is a specific form of decoupling software modules.
Two or more systems that are able to transact without being connected, or coupled. The systems do not interact with each other, and also one system usually has only a very limited knowledge of any other system, and that knowledge is usually limited to information about shared interfaces. A decoupled system allows changes to be made to any one system without having an effect on any other system. Also called uncoupled.
This principle states that high level modules must not depend on low level modules but they should depend on abstraction. In Software engineering, Concretion means an object constructs other required objects inside it. Like the above example class Tree class a objects of class Rose and Lotus which we must avoid.
