SOLID - suniladhya/Advantage GitHub Wiki

1(https://www.qfles.com/interview-question/solid-principles-interview-questions)

SOLID is the Acronym of 5 principles in OOD. Goal:

1. to standardize a project implementation
2. improves understandable, flexible, and maintainable
3. Promotes loose coupling

S - Single Responsibility Principle
O - Open Close Principle (open for extension, but closed for modification)
L - Liskov Substitution Principle
I - Interface Segregation Principle
D - Dependency Inversion Principle\

1. Describe the Single Responsibility Principle (SRP).1

In Object Oriented Programming, Single Responsibility (SRP) ensures that every module or class should be responsible for single functionality supported by the software system. In other words.

Every Module (class) should have one and the only reason to change it. For example, In ASP.NET MVC HomeController class should be responsible related to the Home Page functionality of the software system. But we may have a catch block to write the error logs to a file.

To adhere to the SRP, The error logs to a file should be taken care by ErrorHandler class.

Single purpose => loose coupling

eg. The Higher depends upon other modules for related or additional functionality.

2. Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”.1

Public class SavingAccount  
{  
    //Other method and property and code  
    Public decimal CalculateInterest(AccountType accountType)  
    {  
        If(AccountType==”Regular”)  
        {  
            //Calculate interest for regular saving account based on rules and   
            // regulation of bank  
            Interest = balance * 0.4;  
            If(balance < 1000) interest -= balance * 0.2;  
            If(balance < 50000) interest += amount * 0.4;  
        }  
        else if(AccountType==”Salary”)  
        {  
            //Calculate interest for saving account based on rules and regulation of   
            //bank  
            Interest = balance * 0.5;  
        }  
    }  
} 

It can be replaced by Interface and class implementation. Instead of adding logic with a conditional statement, multiple classes can be created which can improve

1. Testability
2. Won't interfere with existing functionality

Interface ISavingAccount  
{  
   //Other method and property and code  
   decimal CalculateInterest();  
}  
Public Class RegularSavingAccount: ISavingAccount  
{  
  //Other method and property and code related to Regular Saving account  
  Public decimal CalculateInterest()  
  {  
    //Calculate interest for regular saving account based on rules and   
    // regulation of bank  
    Interest = balance * 0.4;  
    If(balance < 1000) interest -= balance * 0.2;  
    If(balance < 50000) interest += amount * 0.4;  
  }  
}  
  
Public Class SalarySavingAccount: ISavingAccount  
{  
  //Other method and property and code related to Salary Saving account`  
  Public decimal CalculateInterest()  
  {  
    //Calculate interest for saving account based on rules and regulations of   
    //bank  
    Interest = balance * 0.5;  
  }  
}  
// for OCP, Modification is restricted and Extension of Functionality should be done.
// The class Account calculateInterest() should be made virtual so that the Extension is made for each of the customized classes.

3. Principle is based on the parent-child relationship 1

4. Client (class implementation interface) should not force to implement an Interface that they don't use. 1

If there is big fat interface then break it into a set of small interfaces with the related method(s) in it. It's similar to normalizing our database like normalizing the database from 1NF to 3NF where a big table is broken into tables with related columns.

Here is an example of a banking customer for a bank with the following types of customers: Corporate customer: For corporate people.

Retail customer: For individual, daily banking.

Potential customer: They are just a bank customer that does not yet hold a product of the bank and it is just a record that is different from corporate and retail.

5. 1 high-level modules should depend on abstraction, not on the details, of low-level modules