SOLID Principles is a coding standard that all developers should have a clear concept for developing software in a proper way to avoid a bad design. It was promoted by Robert C Martin and is used across the object-oriented design spectrum.

Single Responsibility Principle

A class should have one, and only one, reason to change.
One class should only serve one purpose, this does not imply that each class should have only one method but they should all relate directly to the responsibility of the class. All the methods and properties should all work towards the same goal. When a class serves multiple purposes or responsibility then it should be made into a new class.

interface Modem {
  public void dial(String pno);
  public void hangup();
 
 public void send(char c);
  public char recv();
}

Above code violates single responsibility principle, now take a look at below code which has followed single responsibility principle.

interface DataChannel {
 public void send(char c);
  public char recv();
}

interface Connection {
 public void dial(String phn);
  public char hangup();
}

Open Closed Principle

Entities should be open for extension, but closed for modification. Software entities (classes, modules, functions, etc.) be extendable without actually changing the contents of the class you’re extending.

Please look at the following code :

// Open-Close Principle - Bad example
class GraphicEditor {

public void drawShape(Shape s) {
  if (s.m_type==1)
  drawRectangle(s);
  else if (s.m_type==2)
  drawCircle(s);
  } 
  public void drawCircle(Circle r) {....}
  public void drawRectangle(Rectangle r) {....}
}

class Shape {
  int m_type;
}


class Rectangle extends Shape {
  Rectangle() {
  super.m_type=1;
  }
}


class Circle extends Shape {
  Circle() {
  super.m_type=2;
  }
}

Issue with Example,

• Impossible to add a new Shape without modifying GraphEditor
• Important to understand GraphEditor to add a new Shape
• Tight coupling between GraphEditor and Shape
• Difficult to test a specific Shape without involving GraphEditor

So How we can fix this problem see the following code

class GraphicEditor {
  public void drawShape(Shape s) {
  s.draw();
  }
}

class Shape {
  abstract void draw();
}

class Rectangle extends Shape {
  public void draw() {
  // draw the rectangle
  }
}

Liskov Substitution Principle

The Liskov Substitution principle was introduced by Barbara Liskov in her conference keynote “Data abstraction” in 1987. Barbara Liskov and Jeannette Wing formulated the principle succinctly in a 1994 paper as follows:

Let φ(x) be a property provable about objects x of type T.

Then φ(y) should be true for objects y of type S where S is a subtype of T. In simple words, Subclass/derived class should be substitutable for their base/parent class. Basically, it takes care that while coding using interfaces in our code, we not only have a contract of input that the interface receives but also the output returned by different Classes implementing that interface; they should be of the same type.

public class Product
{
    public string Name { get; set; }
    public string Author { get; set; }
}
public class Book : Product  {}
public class Movie : Product  {}

If someone had a Product object (which was actually a Movie) and asked for the Author, what should it do (a Movie doesn’t have an Author)?

People using derived classes should not encounter unexpected results when using your derived class.

Interface Segregation Principle

A Client should not be forced to implement an interface that it doesn’t use. This rule means that we should break our interfaces in many smaller ones, so they better satisfy the exact needs of our clients.

Similar to the Single Responsibility Principle, the goal of the Interface Segregation Principle is to minimize the side consequences and repetition by dividing the software into multiple, independent parts.Let’s see an example :

interface Worker {
  void work();
  void eat();
}
ManWorker implements Worker {
  void work() {…};
  void eat() {30 min break;};
}
RobotWorker implements Worker {
  void work() {…};
  void eat() {//Not Appliciable For a RobotWorker};
}

How we can fix it

interface Workable {
  public void work();
}

interface Feedable{
  public void eat();
} 

Dependency Inversion Principle

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

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

By applying the Dependency Inversion the modules can be easily changed by other modules just changing the dependency module and High-level module will not be affected by any changes to the Low-level module.Wrong use

public class EmployeeService {
  private EmployeeFinder emFinder //concrete class
  public Employee findEmployee(…) {
  emFinder.findEmployee(…)
  }
}

Correct use

public class EmployeeService {
  private IEmployeeFinder emFinder //depends on an abstraction
  public Employee findEmployee(…) {
  emFinder.findEmployee(…)
  }
}

Advantages

• Code becomes more Testably
• Provides a principled way to manage dependency.
• Code that are flexible, robust, and reusable.

Summary

When the developer builds a software following the bad design, the code can become inflexible and more brittle, small changes in the software can result in bugs. For these reasons, we should follow SOLID Principles.