SOLID: The First 5 Principles of Object Oriented Design

Why we use SOLID Principle

1.Coding standard should a clear idea on developing software in a proper way to avoid bad design

2.Easy to understand and modify

SOLID stands for:

S — Single-responsiblity Principle

O — Open-closed Principle

L — Liskov Substitution Principle

I — Interface Segregation Principle

D — Dependency Inversion Principle

Single-Responsibility Principle the class should have only one reason to change it. It doesnt mean it should contain single method .It can have n number of methods associated with the particular class.

Example of violating Single Responsibility Principle

class Employee
{
    private void updateemployeedetails()
    {

    }
    private void getemployeedetails()
    {

    }
    //getemailreport() method violate Single Responsibility    
    private void getemailreport()
    {

    }
}

In the above principle you can see getemailreport() method violates Single Resposibility Principle as its doesnt belong to the class of employee

Example of Single Responsibility Principle

class Employee
{
    private void updateemployeedetails()
    {

    }
    private void getemployeedetails()
    {

    }    
}

Open-closed Principle

Open for extension closed for modification mean we should not modify the existing class that has been tested instead we can create a new code but not changing existing code.

Example violating Open closed Principle

private void interestcalc(String accountype)
{
    int balance =0;
    if(accountype.equals("Regular"))
    {
        balance = 5*2;
    }
    else if(accountype.equals("Saving"))
    {
        balance = 9*2;
    }
    else if(accountype.equals("Current"))
    {
        balance = 10*2;
    }
}

In case in future if you need to add one extra accounttype mean we have to open the existing class and have to make modification with another else if loop this might affect the already tested code.

Example Of Open closed Principle

public interface Iaccount {
    void interestcalc();
}class Regular implements Iaccount
{
    @Override
    public void interestcalc()
    {
       int balance = 5*2;
    }
}
class Saving implements Iaccount
{
    @Override
    public void interestcalc()
    {
       int balance = 5*2;
    }
}
class Current implements Iaccount
{
    @Override
    public void interestcalc()
    {
       int balance = 5*2;
    }
}

In the above example we have created a seprate interface with method interestcalc() and we extend that in three different account class so in future if you want to implement any new account type we can create a new class and extend it without modfying already tested or completed class.

Liskov Substitution Principle

1.The object of the super class should be replaced by the object of the sub class without breaking the application.

2.Object of the subclass should behave in same way of object in super class.

Example of Liskov Substitution Principle

class Employee
{
    public static  void main(String args[])
    {
       fruits obj = new Apple();
       System.out.println(obj.getcolor());
       obj= new Orange();
       System.out.println(obj.getcolor());
    }
}

abstract class fruits
{
    abstract String getcolor();
}

class Apple extends fruits
{
    @Override
    String getcolor() {
        return "Red";
    }
}
class Orange extends fruits
{
    @Override
    String getcolor() {
        return "orange";
    }
}

Interface Segregation Principle

we may not need to call all method of interface on a particular class so inorder to avoid that we will be creating seperate interface that needed for the class

Example of Interface Segregation Principle

interface ShapeInterface
{
    public void area();
}

interface ThreeDimensionalShapeInterface
{
    public void volume();
}

class Cuboid implements ShapeInterface, ThreeDimensionalShapeInterface
{
    public void area()
    {
        // calculate the surface area of the cuboid
    }

    public void volume()
    {
        // calculate the volume of the cuboid
    }
}

Dependency Inversion Principle

High-level module must not depend on the low-level module, but they should depend on abstractions.

It helps acheiving lossely coupled

Example violating Dependency Inversion Principle

class Employee
{
    public static  void main(String args[])
    {
        Apple obj = new Apple();
        obj.getcolour();
    }
}


class Apple
{
   public void getcolour()
   {

   }
}

in the above example Apple class depend on Employee class it means it tigtly copuled in order to make loosely coupeled we can achieve it by abstraction or interface

Example Of Dependency Inversion Principle

public interface Fruits {
    void getcolor();
}class Fruitcolor
{
    public static  void main(String args[])
    {
       Fruits fruits = new Apple();
       fruits.getcolor();
    }
}


class Apple implements Fruits
{
    @Override
    public void getcolor()
    {
       // your code
    }
}