Solid Principle In Detail

Introduction

SOLID principles are the set of principle fist given by Robert.C.Martin. SOLID principle as name given its set of principle that allows building SOLID software system (i.e. Application, Application Module), if one implement software according to this set of principle.

SOLID software system means its allows to build system that is

1. Easy to maintain
2. Easy to extend
3. Easy to understand
4. Easy to implement
5. Easy to explain

SOLID principles are related with the design and maintenance of software system. Most of the developer mix SOLID principles with OOD principles and Design patterns. Below image that removes confusion of OOD principles and Design patterns

Note: This is my interpretation of the arranging thigs.

So as per image

1. OOD Principle (Abstraction, Encapsulation, Inheritance, Polymorphism)
2. SOLID principle
3. Software Design Patterns (GOF patterns, Dependency injection & patterns)
4. Martin Flower’s Enterprise Application Architectures Pattern (additional but required)
5. Domain Driven Design Architecture (additional but required)

S.O.L.I.D is acronym for

1. Single Responsibility Principle

   Principle is related to Designing software module, class or function that should perform only one task. So this principle is about Creation.

2. Open/Close Principle

   Principle is applied after 1 (Single Responsibility Principle), again this principle is related to Designing module, class or function. But it about closing already designed thing for modification but opening designed thing for extension i.e. extending functionality. So this principle is about extension.

3. Liskov Substitution Principle

   Principle is related to substitution of child in place of its parent. So principle is about relationship i.e. inheritance.

4. Interface Segregation Principle

   Principle is related to designing of interfaces as one of the basic rules of designing says depends on abstraction. Principle is about design interface such a way, so that client of interface not force to implement not required things. So principle is about efficient interface design.

5. Dependency Inversion Principle

   Principle is related to designing decoupling modules, classes of software system. This principle mostly applied after 4 (Interface Segregation principle) because interface are one form of abstraction and this principle is related to Details (module/class) should depend on abstraction, and abstraction should not depend on detail. So this principle is about creating loosely coupled system.

Following describes each principle is detail

Single Responsibility Principle

The Single Responsibility Principle is a SOLID principle defined by Robert C. Martin. In principle it says that an implementation (class / function) should perform only one task or implementation and it (class / function) should be changed for only one reason.

So in simple words it says that whatever the developer implements (class / function) in code during development should perform only one task and developer should only have one reason to change the implementation (class / function).

Wrong interpretation of the Principle

Most developers interpret to mean that a class should perform only one task. But it's not only classes, functions you implement in code during development should also perform only one task. So one should interpret it as meaning that an implementation should perform only one task.

Real Life Example of not following Single Responsibility Principle

What happens when one can do more than one task? The following is an image of an example of it.

One can perform multiple tasks, there is no question of that, but it's not going to provide quality / better output.

So to get good quality/better output of work, one should do one task at time.

Example of not following Principle in Application Development

In programming, in other words when developing code as in the following, the Order class is not following the principle.

Public class OrderManager  
{  
    Public List < string > ValidateOrder()  
    {  
        //Code for validation    
    }  

    Public bool SaveOrder(OrderInfo order)   
    {  
        //Code for saving order    
    }  

    Public void NotifyCustomer()  
    {  
        //Code for notification     
　  }  
}

The preceding order class has the following responsibility:

1. ValidateOrder: Validating an order placed by customer and return error message if any
2. SaveOrder: Saving an order placed by the customer and returns true/false
3. NotifyCustomer: Notifies the customer order is placed

Method not following the principle.

public int SumOfAllCustomerOrder(int customerId)  
{  
    int sum = 0;  
    var query = "Select * from order where customerid = " + customerid;;  
    //query orders    
    foreach(Order in OrderCollection)   
    {  
        If(Order.Items.Count > 5)  
        Sum += Order.Price;  
    }  
    return sum;  
}

The preceding method has the following responsibility:

1. Method first all the orders
2. It went through all orders in the collection and does some of that

Following Single Responsibility Principle

To make a class or function follow the Single Responsibility Principle, divide the responsibility by creating new classes or functions as in the following.

Public Class OrderValidator   
{  
    Public List < string > Validate(Order order)   
    { 
        //code for validation   
    }  

    Public Class Notifier   
    {  
        Public void Notify(string emailId)   
        { 
          //code for notification    
        }  

        Public Class OrderManager   
        {  
            Private readonly OrderValidator orderValidator;  
            Private readonly Notifier notifier;  
            Public OrderManager(OrderValidator oValidator, Notifier nFier) {  
                orderValidator = oValidator;  
                notifier = nFier;  
            }  

            Public bool SaveOrder(OrderInfo orderInfo)   
            {  
                //Validate order     
                orderValidator.Validate(orderInfo);　　　 
                //code for saving order //this might be call to repository to save order     
                //notify after successful saving  
                notifier.Notify(orderInfo.EmailId);  
            }  

            Public List < OrderInfo > GetOrders(int customerId) 
            { 
                //code for getting order by cusotmerid    
            }

The preceding code shows the three classes that has only a single responsibility to perform.

For the method it will be like.

public List < OrderInfo > GetOrder(int customerId)  
{  
    int sum = 0;  
    var query = "Select * from order where customerid = " + customerid;;  
    //query orders    
    return ordercollection;  
}  

public int SumOfAllCustomerOrder(int customerId)   
{  
    var OrderCollection = GetOrder(customerId);  
    foreach(Order in OrderCollection)   
    {  
        If(Order.Items.Count > 5)  
            Sum += Order.Price;  
    }  
    return sum;  
}

Note

Following the Single Responsibility doesn't mean one can create a class with only one method.

Disadvantages of not following Single Responsibility Principle

In programming if the developer creates a class/function that performs more than one task then that always causes problems in providing good quality. The following problems are related to a class performing more than one task:

1. It's very difficult for the other developers (in other words developers unfamiliar with the class) to understand the class/function.
2. It's difficult for the other developers to maintain the class/function or change the class/function.
3. Writing test cases for the class/function also becomes difficult.

How to determine if the Single Responsibility Principle has not been followed

1. Try to write a one line description of the class or method, if the description contains words like "And, Or, But or If" then that is a problem. An example of a description of a class as described above that does not follow the single responsibility principle is: “An Order class that performs order saving, notification to the customer and validates the order”.
2. A class constructor takes more than three arguments or a method contains too many parameters.
3. A class or method as an implementation that is is too long.
4. A class that has low cohesion. Read more about cohesion : Cohesion

Open Closed Principle

The Open Closed Principle is one of the SOLID principles defined by Robert C. Martin. The principle says “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”.

So in simple words it says that an implementation (of a class or function), once created, should be closed for further modification, in other words one should not modify an implementation (of a class or function) of logic and/or functionality. One can do refactoring or resolve errors of implementation (of a class or function) but the implementation (of a class or function) is open for extension, in other words one can extend the implementation (of a class or function) of logic and/or functionality.

Real Life Example of Open Closed Principle

An electric adapter is a good example of this principle.

As you can see in the image:

1. An adapter in the wall is always closed for modification, in other words we cannot change it once it is fitted or extended if we want more.
2. But an adapter always provides a method of extension, so we can plug in an extension board of an adapter for more adaptation.
3. So you plug in an extension board and extend an existing electric adapter fitted in wall.

Example of not following the principle in Application Development

A bank offers various types of the savings accounts (Salary Saving, Regular Saving and so on) that meet the needs of many types of customers. A bank has differing sets of rules and each savings account type has a different set of rules to calculate interest.

To calculate the interest of an account, developers have developed the following class with methods to calculate interest.

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;  
        }  
    }  
}

So in the preceding code the SavingAccount class's CalculateInterest method does a calcualtion based on the account type like Salary and Regular.

So the implementation is not following the Open Closed principle because if tomorrow the bank introduces a new SavingAccount type then there is a requirement to modify this method for adding a new case for the new account type. An example is if the bank introduces a “Child Savings Account type” requiring a new condition for calculating the interest for this account type. That means that the method is always open for modification.

One more thing to note here is that the method is also not following the Single Responsibility Principle. Since here the method is doing more than one thing, like calculating interest for more than one type.

How to Implement the Open Closed Principle

Inheritance is only one way to implement the Open Closed Principle. Because inheritance is only an Object Oriented Design (OOD) basic pillar that allows extension of functionality of an existing class.

To implement the Open Closed Principle one can use interface, an abstract class, abstract methods and virtual methods than inherit them when you want to extend functionality.

So the preceding problem of a Savings Account can be resolved as in the following.

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 regulation of   
    //bank  
    Interest = balance * 0.5;  
  }  
}

In the preceding code two new classes are created, RgularSavingAccount and SalarySavingAccount, that is inherited from IsavingAccount.

So if there is a new account added by the bank than there is no need to modify the logic of exiting classes, just extend the functionality by inheriting an interface.

Finally the preceding example implements the Open Closed Principle since there is no need to modify the existing implemented logic and it allows extension for adding new logic.

And the preceding example also implements the Single Responsibility Principle since each class or function is doing only one task.

Note : An interface is created here just as an example. There could be an abstract class of SavingAccount that is implemented by a new savings account type.

Disadvantage of not following Open Closed Principle

1. Since a class or function always allows the addition of new logic, whenever new logic is added it is always necessary to test for full functionality. That requires the addition of a new test case for the added functionality and might also require the modification of an existing test case that fails because of added functionality.
2. It also breaks the Single Responsibility Principle since a class or function might end up doing multiple tasks.
3. Class or function maintenance becomes difficult since a class or function can become thousands of lines of code that is difficult to understand.

How to Identify not following Single Responsibility Principle

• A class or function is always open for modification, in other words always allows adding more logic to it. Like in the preceding example.

Liskov Substitution Principle

Liskov Substitution Principle – is one of the SOLID principles defined by Barbara Liskov. Principle is based on the parent-child relationship in other words inheritance features of OOD (Object Oriented Design). Principle says “When class S is a subtype of class T then an object of type T can be replaced by an object of type S without affecting functionality/correctness of the implementation or program”.

In simple words it says “Places in implementation (Class/Function) that use a base class, in other words consume a service of a base class, must work correctly when the base class object is replaced by a child class (derived class) object.”

Liskov Substitution Principle in Real life

The following is an example of an electric bulb that actually violates substitution. When the bulb fails it is replaced with a new bulb. Here in this example the old bulb is replaced with the new bulb.

Perfect Substitution

Note

Here in this example in the family of bulbs, considering the old bulb to be a parent of all bulb types and a CFG bulb is a child of the same family inherited from it.

When one replaces a failed bulb, in other words in programming terms substitutes the old with the new, it must provide light that is provided by the old bulb, in other words works without affecting correctness or functionality (provides a constant light in the house). In the preceding example the substitution worked perfectly since there is no modification in functionality.

Violation Example

The preceding image shows the violation of the principle. Since replacing with a decoration bulb (that provides light in the form of decoration) instead of a bulb meant for just providing light in the house. That actually is a violation in the sense of modifying the functionality because a decoration bulb does not provide the same functionality for the consumer.

Example of not following Principle in Application Development

Continuing with bank savings account that is already explained in previous articles about the Open-Closed Principle.

Interface ISavingAccount  
{  
   //Other method and property and code  
   bool Withdrwal(decimal amount);  
}  

  

Public Class RegularSavingAccount : ISavingAccount  
{  
  //Other method and property and code related to Regular Saving account  
   Public bool Withdrwal ()  
  {  
    Decimal moneyAfterWithdrawal = Balance-amount;  
    if(moneyAfterWithdrawal >= 1000)  
    {  
       //update balace   
       return true;  
    }  
   else  
     return false;  
  }  
}  

  

Public Class SalarySavingAccount : ISavingAccount  
{  
  //Other method and property and code related to Salary Saving account`  
   Public bool Withdrwal ()  
  {  
    Decimal moneyAfterWithdrawal = Balance-amount;  
    if(moneyAfterWithdrawal >= 0)  
    {  
       //update balace   
       return true;  
    }  
    else  
       return false;  
  }  
}  

Public Class FixDepositSavingAccount : ISavingAccount  
{  
  //Other method and property and code related to Salary Saving account`  
   Public bool Withdrwal ()  
   {  
     Throw New Excpetion("Not supported by this account type");  
   }  
}

In the preceding code the IsavingAccount interface is implemented by a different kind of savings account of the bank, like Regular, Salary and FixDeposit savings account.

But as per the banking rules, a FixDeposit savings account doesn't provide a withdrawal facility whereas another bank account might provide a withdrawal facility.

So the developer might write code to raise an exception when an attempt is made to withdraw from a FixDeposit savings account.

Now consider the following method in a class calling a withdrawal by casting the actual object to the parent class type.

Public class AccountManager  
{  
  Public bool WithdrawFromAccount(IsavingAccount account)  
  {  
    account.Withdraw(amount);  
  }  
}

The following code calls the method,

//works ok  
AccountManager.WidhdrawFromAccount(new RegularSavingAccount());  
//works ok  
AccountManager.WidhdrawFromAccount(new SalarySavingAccount());  
//throws exception as withdrawal is not supported  
AccountManager.WidhdrawFromAccount(new FixDepositSavingAccount());

Violation of Liskov Substitution Rule

So the preceding code breaks the Liskov Substitution rule since the inherited FixDepositSavingAccount class is modifying the functionality of the withdrawal. Because the savings account should provide functionality to withdraw an amount without throwing any error.

How to stop violating the rule

To stop violating the rule one must verify the inheritance tree, in other words child classes inherited from the parent class should not break the functionality when the child class object replaces the parent class object.

So the class must inherit from the proper parent class in such a way that when the child class replaces the parent, it doesn't break the actual functionality provided by the parent class.

Note

It's not always true that one must make changes in the inheritance tree but making changes at the class and method level also resolves problems. To get such kind of example click on the link: Object Menter (Square and rectangle example).

In the preceding image the new classes WithWithdrawal and WithoutWithdrawal are created and the child classes are inherited from the respective parent class.

So in the preceding code:

Interface ISavingAccount  
{}  

Public Class SavingAccountWithWithdrawal : ISavingAccount  
{  
    Public virtual bool Withdrwal () {}  
}  

Public Class SavingAccountWithoutWithdrawal : ISavingAccount  
{  

}  

Public Class RegularSavingAccount : SavingAccountWithWithdrawal  
{   

  Public bool Withdrwal ()  
  { 
     //implementation  
  }  
}  

Public Class SalarySavingAccount : SavingAccountWithWithdrawal  
{   
  Public bool Withdrwal ()  
  {//implementation  
  }  
}  

Public Class FixDepositSavingAccount : SavingAccountWithoutWithdrawal  
{  

}

Now using it:

Public class AccountManager  
{  

   Public bool WithdrawFromAccount(SavingAccountWithWithdrawal account)  
   {  
      account.Withdraw(amount);  
   }  
}

Now the following code to call method:

//works ok  
AccountManager.WidhdrawFromAccount(new RegularSavingAccount());  
//works ok  
AccountManager.WidhdrawFromAccount(new SalarySavingAccount());  
//compiler gives error   
AccountManager.WidhdrawFromAccount(new FixDepositSavingAccount());

Disadvantage of not following the Liskov Substitution Principle

• Developed code throws a run time error or exception or also might not work as expected and that leads to program failure or incorrect results.
• The preceding discussion shows an example of throwing an exeption by a child class for a not supported method.
• Read link: Object Mentor that shows an example (square and rectangle example) of giving incorrect results when not following the principle.

So the biggest advantage of not following this rule is: it causes problems at runtime rather than causes application failure or incorrect results.

Interface Segregation Principle

The Interface Segregation Principle is one of the SOLID principles defined by Robert C. Martin. It is one of the rules of software development that says to always code according to a contract, in other words an interface, not against the implementation, in other words a concrete class, because coding against an interface provides advantages like flexibility, loose coupling, testable code and so on. This principle is related to creating an interface for implementation.

The principle says “Client (class implementation interface) should not force to implement Interface that they don't use.” In simple words the principle is saying, do not design a big fat interface that forces the client to implement a method that is not required by it, instead design a small interface. So by doing this class only implement the required set of interface(s).

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 database from 1NF to 3NF where a big table is broken into tables with related columns.

Interface Segregation Principle in Real life

In terms of the violation of the ISP, the following image shows a big dustbin for throwing all kinds of garbage away without any kind of segregation.

With ISP, the following image is a good example of segregation in our real life.

That is an image of a waste bin segregation that shows which one to use for throwing away trash we use.

Example of ISP in Application Development

Here is an example of a banking customer for a bank with the following types of customers:

1. Corporate customer: For corporate people.
2. Retail customer: For individual, daily banking.
3. 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.

The developer of a system defines an interface for a customer as in the following that doesn't follow the ISP rule.

It looks OK at first glance but it's a big fat interface for the customer with problem since it forces the client class to implement methods that are not required.

1. A potential customer as described taht does not hold any product is forced to implement a product property.
2. A potential customer and a retail customer both are forced to have a Customer Structure property but in a real scenario a Corporate customer has a Customer Structure that describes a customer hierarchy.
3. A potential customer and a retail customer both are forced to implement a BusinessType but that just belongs to a corporate customer.
4. A corporate customer and a potential customer are forced to implement an Occupation property that is just a blog to a retail customer.

A solution to the preceding problem is to split the fat interface into meaningfull parts, in other words small interfaces, so the customer type only implements the interface that is required by it.

The following is an image that follows the ISP:

Disadvantages

1. Deliver big fat interface that forces the client to implement a method that is not required.
2. The client ends up implementing a usefuless method, in other words a method that has no meaning to the client. This decreases the readability of the code and also confuses the developer using the client code.
3. The client interface ends up violating SRP sometime since it might perform some action that is not related to it.

Dependency Inversion Principle

The Dependency Inversion Principle is one of the SOLID principles defined by Robert C. Martin. This principle is about dependencies among the components (such as two modules, two classes) of the software.

The principle says that high-level modules should depend on abstraction, not on the details, of low level modules, in other words not the implementation of the low level module. Abstraction should not depend on details. Details should depend on abstraction. In simple words the principle says that there should not be a tight coupling among components (in other words two modules, two classes) of software and to avoid that, the components should depend on abstraction, in other words a contract (interface or abstract class).

Dependency Inversion Principle in Real life

To understand the second problem better way, let's see a real life scenario of a computer or laptop.

As you can see in the preceding image we have a port for each external device to which I can associate an external device and do our work.

But the problem with this is, I cannot attach my keyboard to a printer port and vice versa. The same problem occurs with the other devices. So this is like a tight coupling, that I cannot change my external device on the given interface, in other words on which I depend.

Solution to this is USB port.

If I have a USB port then I can easily attach any device to my machine and perform my task.

Example of Dependency Inversion Principle in Application Development

The following is a class diagram of tight coupling that does not follow the principle.

Public Class Customer  
{  
    CustomerRepository CustomerRepository;  
    Public Customer  
    {  
        CustomerRepository = new CustomerRpository();  
    }  

    Public bool Save()  
    {  
        CustomerRepository.Save();  
    }  
}  

Public class CustomerRepository  
{  
    Public bool Save(dattype data)  
    {  
              //Sql Connection object and Save data in Sql server   
    }  
}

The preceding code is tightly coupled because the current repository deals with the SQL server. So if the requirement is to use an Oracle server then there is modification required for the Customer class.

So to avoid that, make the customer class depend on abstraction. The following is an image of a class diagram where the customer depends on abstraction and supports both SQL and Oracle servers.

Public Class Customer   
{  
    CustomerRepository CustomerRepository;  
    Public Customer   
    {  
        CustomerRepository = new CustomerRpository();  
    }  

    Public bool Save()   
    {  
        CustomerRepository.Save();  
    }  
}  

  

Public class CustomerRepository   
{  
    Public bool Save(dattype data)   
    {  
        //Sql Connection object and Save data in Sql server     
    }  
}

So in the preceding code the customer class depends on ICustomerRepository abstraction, in other words an interface. Another thing is here the customer class receives a dependency via consumption of the customer class or using a dependency container.

Note: Here is an example of the class but the same goes for the modules designed in software because dependency inversion is about providing a set of abstraction policies on which the details depend and the policy that provides flexibility in the software system.

Disadvantages Application modules become tightly coupled, that means:

1. The testability of the module becomes difficult.
2. Parallel development of the module becomes difficult.
3. Many changes are required when there is modification in the module and when there are changes in the module it depends on.

Note: Dependency Injection is not the same as Dependency Inversion because Dependency Inversion is about defining an abstraction policy for the software module whereas Dependency Injection is a set of patterns to supply dependency.