S.O.L.I.D Principles for beginners (Part 1)

Introduction

This article is created for all the junior programmers who are interested in taking themselves to the next level of Software Development. In one of the previous post, I mentioned about some of the software development tips; it was some of the basic things to follow while developing software. But, this article can be considered as an advanced version of that post.

Please not that “This post is not meant for experts.” I am just trying to ease the understanding of principles for beginners. My intention is to take enthusiastic programmer to the next level. I am trying to explain the concepts in terms of examples with C#. Experts, if you see any mistakes in this article, kindly comment. I will review and update it, so that the beginners are able to understand it clearly; I did a lot of research in SOLID principles and this article is a summarized version of my understanding from all of the research.

What are SOLID principles?

These are some of the basic principles a lead developer should know while developing software. It allows you to structure the program with much better maintainability and scalability / extensibility. This can be considered as the foundation of a well-designed application.

Single Responsibility Principle (SRP)

Definition: A class should have only one reason to change;

Scenario: We are creating an application for a client; let’s call him Mr. X. He runs a logistics company. Mr. X’s requirement is to have an entry module to process shipments for his customers. So, we created a customer class with basic customer details and a method to process shipments. Mr. X started using the program and he was happy until he got an international contract. He also wanted a new payment method to be added for international transactions. We then edit the customer class to accept international shipment. Then after the next review, the Mr. X asked us to add additional bank type, current or savings and bank account number to be verified based on type. Now the class is getting complicated. It is now maintaining bank details along with customer details with validations and the process shipment method. Things will get more complicated if Mr. X wants to add a third type of shipment or bank!

The above mentioned class violates all the SOLID principles; we will see how this class is violating the SOLID principles as we progress. The class is now too complicated and maintaining this class will make the developers life in hell.

Customer class the violates SRP

public class Customer

{

    public string CustomerName { get; set; }

    public string Phone { get; set; }

    public string BankAccountNumber { get; set; }

    public void Process()

    {

        // Validate bank account number        

        // Validate phone number        

        // Save customer details with 

        // bank account and contact number

        // Process Shipment

    }

}

How is the above class violating SRP?

In the above example, there is more than one reason to change the customer class. I hope you have an understanding on why we should implement SRP in your project. SRP is very easy to understand, but not that easy to implement! You may need clear vision about what will the project be like and what are the possible changes that are likely to happen for the project in the future.

Scenario is simple and now, you might have an idea of how to split the class to implement SRP. The above example is definitely a violation of SRP and we should split the class in order to implement SRP.

How should we split?

Customer: Basic details of the customer should be in a single class. Bank account details should be in another class. There is one more. Communication!!! WHY??? As you can see, the only possible requirement other than customer basic entry is with respect to the Communication. There can be a new requirement to validate phone number, email etc. or to add an additional email or a condition to validate an email id.

See the below example. Here the bank account details is a separate entity that is defined in a different class. If there is any change or validation to be added to bank details, it can be done in that specific class. 

public class Customer : ICustomerDetails
{
public string CustomerName { get; set; }

public IBankAccount BankAccountDetails { get; set; }

public Customer(IBankAccount bankAccountDetails)
        {
        this.CustomerName = "Neal Gabriel";
                this.BankAccountDetails = bankAccountDetails;
        }

}

Thank you for reading the post. Please comment to make this post better.