what is solid principles | what are solid principles | what are solid principles in java

What are solid principles

When we talk about design patterns, SOLID is very very important and fundamental principle. This blog is designed to explore every aspect of solid design principle.

In Object Oriented Programming, SOLID is acronyms for five design principle. Together these principle makes your application software more understandable, flexible and maintainable.

The theory about SOLID principle is introduced by Robert C. Martin  in the year 2000.

SOLID acronym

Single responsibility principle

A class should only have a single responsibility.

Open–closed principle

Software entities should be open for extension, but closed for modification.

Liskov substitution principle

Objects in a program should be replaceable with instances of their subtypes without altering

Interface segregation principle

Many client-specific interfaces are better than one interface.

Dependency inversion principle

One should depend upon abstractions not concretions.

S - Single Responsibility Principle

This means each and every class should focus on only one / single task.

Example with multiple responsibility:

Here we have Agent class that has three responsibility 

1. createCustomer.
2. calculateSubscriptionPrice
3. emailCustomerDetails

So this code certainly breaking single responsibility principle

Let's refactor this class as : -

• Agent - create only customer.
• SubscriptionManager - manage subscription details.
• Mailer - for notification like email / sms.

Notice there Agent class has single responsibility to create customer.  State name removal and subscription price logic or any change in email send logic does not impact Agent class.

Now look at SubscriptionManager class, calculation of subscription price is decoupled from  Agent class. It has now single responsibility.

This Mailer class has only responsibility to send mail.

Now Running the Application.

So in a nutshell We can say Single Responsibility Principle Allow us to reduce coupling of responsibility of a class so that they can be used independently.

O -  Open-Closed Principle

Modules, Class, Functions should be open for extension but close for modification. In other words we can say we should design our class in such a way that you can extend in child class through Inheritance,  once you have inheritance no need to be changed in existing class or module.

Example :

Let's analysis this code.

• The problem with this code is, It's breaking SRP (Single Responsibility Principle). This class has two responsibilities first one is to generate Invoice and second one is to generate Shipping Report.
• Another problem with this code is,  It's not flexible, If we want to add shipping address into the report, the class has to be modified. This breaks Open-Close Principle.

Let's Refactor this code.

• OrderReport : Parent class
• Invoice : Child class of OrderReport
• ShippingInvoice : Child class of OrderReport

Main Class

Making OrderReport class Parent with Core function and both Invoice and ShipingInvoice Inherit from it will give feature of extension. 

Does not required to modify existing just extend once and give additional feature like ShipingInvoice adding additional feature for address.

L — Liskov Substitution Principle

This says, Classes should be design in such a way that they are able to replace any instance of it's parent class with an instance of one of its child classes without any problem.

This requires that objects of your subclass should beehive in the same way as the objects of super class. This means you can implement less restrictive validations rule but not allowed to enforce stricter rule in your sub class.
  

Let's understand this with example

We have to find what's wrong with this code first then we will optimise our code

Now creating subclass PermanentEmployee of Employee

TemporaryEmployee

ContractEmployee

The problem with this ContractEmployee class is that, This class violates Liskov Substitution Principle because Contract Employee getBonus method are not behaving the same way.

Main Application

Till now you are aware of what's wrong with design. let's redesign this assignment.

## Moving abstract method from Employee class and making it concrete 

## Create Interface Bonus Interface

##  Create ParmanentEmployee class

## Create TemporaryEmployee class 

## Create ContractEmployee class 

## Main Application class

So with this design of code we have removed our getBonus method from Employee class to Bonus Interface, We only implement Bonus interface to those class who are eligible for bonus.

I — Interface Segregation Principle

Interface segregation say's that your code should not be forced to implement method that it does not use.

Example:

Now i just have to print content so i only need printContent method

But here problem is if i implements PrintOptions interface then i have to give implementation for all the method of PrintOptions interface.

Also if we add any method in PrintOptions then we have to modify every class that implement PrintOptions Interface.

Now let's refactor these assignment.

public interface Printer{

       public boolean printContent(String content);

}

public interface Fax{

       public boolean faxContent (String content);

}

public interface PhotoCopy{

      public boolean photoCopy(String content);

} 

Now Each interface has it's relevant method so according to requirement these interface can be implemented.

public class CanonPrinter implements Printer{

       public boolean printContent(String content){

             System.out.println(content);

             return true;

       }

}  

So we don't have to implement unnecessary method here.

D — Dependency Inversion Principle

This says High level module should not depend upon low level module. It should depend on abstraction.

Dependency can be achieve in two ways.

1. Constructor Injection.
2. Method Injection.

Conclusion :

SOLID principle makes software design flexibility, understandable, maintainable.