S.O.L.I.D Principle

Simple and easy way to understand:

What is the Purpose behind the SOLID principle?

We always need to build readable and testable code, for achieving this we need to follow some Design Principles right? Yes, so the use of the S.O.L.I.D Principle is to achieve a maintainable and clean code base.

Let's see step-wise

1. Single responsible Principle →

A class should be responsible for only one purpose, it means there should be only one reason to modify or change. What does it mean?🤔

Let's take an example of a Data class — we can modify the Data class only when an entity change is requested.

Another example is the Recycler View adapter — the recycler view class is responsible to show the Data in the list, and if we need to modify the displaying data, then we need to change it in onBindViewHolder(). Because only the adapter class is responsible to show data.

2. Open-Closed Principle → Classes, functions, and modules should be open for extension and closed for modification. It means if we need to add a new feature, instead of editing the existing one, we should create a new one. We can use Abstract or Interface classes to achieve the Open-closed principle.

Let's take a quick example — Violation of Open Closed principle

public class Triangle{
    public double base;
    public double height;
}

public class Square{
    public double side;
}

public class AreaCalculate{

public double getTriangleArea(Triangle triangle){
        return   area = (triangle.base * triangle.height)/2;
    }

public double getSquareArea(Square square){
        return   square.side * square.side;
    }

After using the Open -Close principle,

public interface Shape{
    public double getArea();
}

public class Triangle implements Shape{
    double base;
    double height;
    public double getArea(){
        return (base * height)/2;
    }
}
public class Square implements Shape{
    public double side;
    public double getArea(){
        return side * side;
    }
}

public class AreaCalculate{
    public double getShapeArea(Shape shape){
        return shape.getArea();
    }
}

3. Liskov’s Substitution Principle →

The Liskov Substitution Principle states that subclasses should be substitutable for their base classes.ex- Inheritance

This means, 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.

In a simple line, a subclass should override the parent class.

4. Interface Segregation Principle (ISP)->

This principle states that none of the classes should be forced to depend on methods that are not in use.

It means when we are creating the interface, we need to split it into smaller interfaces so that other classes do not need to implement all the unnecessary methods.

5. Dependency Inversion Principle (DIP)->

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Abstractions should not depend upon details. Details should depend upon abstractions.

Conclusion — we got to know that 1️⃣ SRP explains the high-level architecture, 2️⃣O/C principle is about the design and feature extension. 3️⃣LSP is about subtyping and inheritance. 4️⃣ISP is about business logic and code communication. 5️⃣DIP is about the overall architecture of the project and following all the above principles.

See you soon….