SOLID Principle

579

S-> Single Responsibility
O-> Open/Closed Principle
L-> Liskov's Substitution Principle
I-> Interface Segregration
D-> Dependency Inversion
__________________________________________________________________________________________________________________________________________________________________________________________________________

Class Should have a Single Responsivility or Purpose.
Accurate Defination: A class Should have only one reason to change.

A software entity(class, method) should have only one reason to change.
If a class or a method does more than one responsibility, it is advisable to separate it into two distinct classes/methods.

__________________________________________________________________________________________________________________________________________________________________________________________________________

We should able to extend a class behavior without modifying it.

Accurate Defination: Software entities should be open for Extension, but closed for modification.

It states that the design and writing of the code should be done in such a way that the new functionality should be added with minimal changes in the existing code.
you should be able to extend a class behavior, without modifying it.

class x is a subtype of class y
Then we should be able to replace y with x without interrupting the behaviour or logic of code.
Accurate Defination: Derived or child classes must be substitutable for their base or parent classes.

This principle shows that polymorphism is both powerful and tricky : in the real world, the usage of polymorphism often leads to a dead-end situation, it must be wisely used.
LSP is often summarized with a counter-example of Duck Test: “If it looks like a duck, quacks like a duck, but needs batteries – you probably have the wrong abstraction”

This principle applies to interfaces instead of classes in SOLID.
Accurate Defination: Do not force any client to implement an interface which is irrelevant to them.

We sometimes need to implement the interface for a few methods defined in that interface. But for the sake, we end up defining all the methods mentioned in the interface. This is known as “fat interfaces “.To avoid such implementations from the system we should follow the interface segregation principle.
It is not a good practice if an interface having lots of methods. We should separate them in a smaller interface.
No class should be forced to depend on methods it does not use.

Note: Dependency Inversion != Dependency Injection
Use abstract classes and interfaces instead of concrete implementation.
Accurate Defination: High-level modules should not depend on the low-level module but both should depend on the abstration.

We usually create low-level modules and high-level modules while designing the software.Generally, high-level modules depend on low-level modules, So if we want to replace the low-level module then we need to make a change in high-level module implementation. To avoid such conditions we need to make sure that High-level modules are independent of Low-level modules. We can achieve this by using Abstraction and abstract layers in between high-level and low-level modules.
we should avoid tightly coupled code. Avoid creating an object of a class using the new keyword, it results in a class tightly coupled to another class.
It helps to create loosely coupled modules. The module should depend on abstraction.

Coding Example :
Let's begin with one coding example
__________________________________________________________________________________________________________________________________________________________________________________________________________

Comments (1)