Solid Principal in Object Oriented Programming

Solid principals are known for best software development practice, here we learn what are the solid principals and how we can implement solid principal in object oriented programming.

solid principal object oriented programming

Before understanding solid principal in object-oriented programming, you must understand OOP Concept (if you are not familiar already)

There are five SOLID principals for creating good software architecture.

  1. S is single responsibility principle (SRP)
  2. O stands for open closed principle (OCP)
  3. L Liskov substitution principle (LSP)
  4. I interface segregation principle (ISP)
  5. D Dependency injection principle (DIP)

Now let's understand each principal with examples, in this example I will be using C# as programming language, you can use any programming language you want, the syntax may differ but the principal remain the same.

Single Responsibility Principle

This principal is very simple to remember, one responsibility at a time, apart from software development this practice can help in your regular life to achieve more.

In object oriented programming when we create any object, we need to remember that object should be designed for carrying out only one of job at a time. So when we create an instance of that object we will not unnecessary occupy memory for other objects and when we make changes in that object definition that will not impact other functionality of different object.

Single Responsibility Principle

Let's understand the above example.

Think of scenario like we have to create functionalities like a driver will join and then start car, stop car and leave the place.

Now we can simply create a class with any name like DriveCar, then create four functions like CarStart, Car Stop, DriverJoin, DriverLeave, that will solve the purpose, but as per SRP Principal, this will be considered as wrong design.

Right design would be, we have to design two separate class, let’s say Car and Driver, then in car class we should create Start and Stop function, and then in driver class we should create Join and Leave function, single responsibility principal helps creating clean design which is easily maintainable and enhanceable.

Open Closed Principle

This principal says any software module or class should be always open for extension and closed for modification.

open closed principle

abstract class BankAccount
{
    public abstract decimal GetInterest();
}
class SavingAccount : BankAccount
{
    public override decimal GetInterest()
    {
        decimal _interest = (decimal)5.6;
        return _interest;
    }
}
class BusinessAccount : BankAccount
{
    public override decimal GetInterest()
    {
        decimal _interest = (decimal)3.6;
        return _interest;
    }
}

Now if you see the above code example we have an abstract class "BankAccount", then we have two type of account like SavingAccount and BusinessAccount, tomorrow if we need another new type of account like ChildAccount, then we can inherit from BankAccount class.

Liskov Substitution Principle

Liskov principle says that a child class should not break parent class’s type definition and behaviour, so let’s consider a real-time business scenario where we keep hiring different type of workforce for any organization, some are considered as permanent employee, some are contractual employee.

Liskov Substitution Principle

abstract class People
{
    public string FullName { get; set; }
    public string Mobile { get; set; }
}
class Employee : People, IContract
{
    public void SignContract()
    {
        Console.WriteLine("Signed contract successfully");
    }
}
class TempWorker : People
    {       
    }
    
interface IContract
    {
        void SignContract();
    }

Instead of creating SignContract method in People class, we have created an interface IContract, otherwise the child class TempWorker would have ignored the implementation of SignContract method by throwing not implemented exception.

Interface Segregation Principle

This principle states that any client should not be forced to use an method of any interface which is irrelevant to it.

Interface Segregation Principle

Let's understand the above ICar interface design , we want to design a car interface with functionalities like Start, Stop, Fill Petrol, and the interface to be consumed by different type of car class like Petrol car and electric car.

Now one approach could be creating one interface and put all three functions there, and PetrolCar and ElectricCar would inherit from that interface, as a result, even though electric car does not need fill petrol function, but forced to implement the function, that will break the ISP principal.

Ideal design would be to create a separate interface for fill petrol function, then use that for petrol car like PetrolCar: ICar, IFuel and for ElectricCar: ICar, so it will not force client to implement the unwanted function.

Dependency Injection Principle

The Dependency Inversion Principle (DIP) says that any high-level classes should not depend on low-level classes, any instance of a class should be created by consumer class.

Look at this Dependency Injection C# example

You should also read following posts

Good to Read
You may also read
Two Step Authentication in Asp.net Core
Two Step Authentication in Asp.net Core
AI and Machine Learning
AI and Machine Learning
Machine Learning Regression analysis using C#
Regression analysis in C# machine learning