Solid principles in Software Programming

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

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

There are five SOLID principles 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)

Solid principles Implementation

Now let's understand each principles 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.

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.

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.

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

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 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.

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.

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

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.

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

• What is Design Patterns?
• What is Factory Pattern and Abstract Factory ?
• How to write clean code and follow best practices