In s/w development, object oriented design plays an important role when it comes to writing flexible, scalable, maintainable & reusable code. Every developer should have the knowledge of the SOLID principles for good object-oriented design in programming.
Following the SOLID acronym-
- Single Responsibility Principle
- Open-Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
Single Responsibility Principle
This principle states that a class should have only a single reason to change which means every class should have a single responsibility or single job or single purpose.
Most of the time it happens that when programmers have to add features or new behavior they implement everything into the existing class which is completely wrong. It makes their code lengthy, complex and consumes time when later something needs to be modified.
Open-Closed Principle
This principle states that software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification which means you should be able to extend a class behavior, without modifying it. We should be able to add new functionality without touching the existing code for the class. This is because whenever we modify the existing code, we are taking the risk of creating potential bugs. So we should avoid touching the tested and reliable (mostly) production code if possible.
But how are we going to add new functionality without touching the class. It is usually done with the help of interfaces and abstract classes.
Liskov Substitution Principle
The Liskov Substitution Principle states that subclasses should be substitutable for their base classes.
This means that, given that class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A and the method should not give any weird output in that case. when we use inheritance we assume that the child class inherits everything that the superclass has. The child class extends the behavior but never narrows it down.
Interface Segregation Principle
Segregation means keeping things separated, and the Interface Segregation Principle is about separating the interfaces. The principle states that many client-specific interfaces are better than one general-purpose interface. Clients should not be forced to implement a function they do no need.
Dependency Inversion Principle
The Dependency Inversion principle states that our classes should depend upon interfaces or abstract classes instead of concrete classes and functions. High-level modules/classes should not depend on low-level modules/classes. Both should depend upon abstractions.
A high module or class is dependent more on low-level modules or classes then the code is tightly coupled and if you try to make a change in one class it can break another class which is risky . So always try to make classes loosely coupled and this can achieved through abstraction. The main motive of this principle is decoupling the dependencies so if class A changes the class B doesn’t need to care or know about the changes.
SAPCODES 