SOLID | Open Closed Principle (OCP)

Open Closed Principle (OCP)

A class can be open for extension and closed for modification. 

Points to remember,  

• Software needs to be flexible, saying that it should have the ability to accept the various changes
• OCP helps to make application flexible enough to accept the new behavior rather than changing the old one
• So new implementation would go in new classes and logic but nothing can be changed in the existing implementation
• Helps to maintain the code easily without breaking the whole thing
• The best way to remember is an electric adapter in your wall, once fitted it's close for modification but open for extension using an external adapter. 

Example with initial implementation of Employee class,

public class Employee
{

        public void CalculateSalary(Employee employee)

        {

              if(employee.Type == "Permenent")

                    //Salary calculation and print the same

              else if(employee.Type == "Contract")

                    //Salary calculation and print the same

        }

}

Now, the above class looks great as it has an Employee and it calculates salary based on their type of Permanent and Contract. And because it is not following the open closed principle adding a new EmployeeType would require a whole class to be changed. 

Now, Thinking the same example with Open Closed Principle,

public interface IEmployee

{

        void CalculateSalary(Employee employee);

}

public class PermenentEmployee: IEmployee

{

         public void CalculateSalary(Employee employee)

        {

              //Salary calculation and print the same

        }

}

public class ContractEmployee: IEmployee

{

         public void CalculateSalary(Employee employee)

        {

              //Salary calculation and print the same

        }

}

public class TemporaryEmployee: IEmployee

{

         public void CalculateSalary(Employee employee)

        {

              //Salary calculation and print the same

        }

}

Now, we have created an Interface and whole new classes to have the ability to create new Employee Types rather than changing the class all the time. Modifying existing implementation would not be a good idea at all. 

The interface IEmployee shares a common contract and that can be shared across derived classes. Now in this example also has a loop whole, let me know if you can find it another way. 

Why use the Open Closed principle?    

• Software needs flexibility to change, and as per the above example if requirements are quite extending the same functionality then we can have a better approach toward the open-closed principle
• It is also breaking another first princple of SOlID that is Single Responsibility, The above class had a multiple responsibility and we have devided that into their own territory so in future if anything comes up, no modification will be done in existing code
• Maintenance becomes more convenient   

In conclusion, I would say, Open Closed Principle also requires implementation of Single Responsibility Principle, Breaking responsibilities from a single entity, and making a framework in a way that is open for extension and closed for modification meets the goal. 

SOLID | Single Responsibility Principle (SRP)

Single Responsibility Principle (SRP)

Introduced by Robert C. Martin, defines responsibility as a single reason to change the class.

• A class should have only one job to do
• It should have a single purpose to serve
• By a single purpose and responsibility it does not mean to be a small class with limited members in it, it can have many but it should point to a single purpose. 
• It helps to separate the classes at the first design phase so that the complexity can be reduced and can be more extensible

Example,

public class UserService
{
    //Create user

   public void CreateNewUser()

   {

        //New user creation implementation

        //Send an email alert

        SendEmail();

    }

    //Sending an email with user-created

    public void SendEmail()
    {

        //Email sending implementation

    }

}

A developer would only be able to understand only when he or she has a clear picture of what needs to be implemented according to the requirement. 

The above example shows two methods kind of user registration which registers the user and sends an alert email. The implementation is short and sweet to understand and it looks good at the first level. But as we are looking at the single responsibility principle you can have an idea of what is wrong with it. 

Let's redesign that with Single Responsibility Principle, 

public class UserService
{
    //Create user

   public void CreateNewUser()

   {

        //New user creation implementation

        

        //Send an email alert

        EmailService.SendEmail();

    }

}

public static class EmailService
{

    //Sending an email with user-created

    public void SendEmail()
    {

        //Email sending implementation

    }

}

Now, we have created a separate class for EmailService which can only contain email-related methods. UserService should have user related tasks in it. If SendEmail() method is part of the same service then at any other service if it needs to consume it would be a redundant code. At this level the same thing becomes reusable.

 

SOLID Design Principles

SOLID Design Principles

SOLID is an acronym for design principles, let's look at it

• Single Responsibility Principle
• A class should have one and only one reason to change
• Open Closed Principle
• The class can be extended without modifying it. So it's open for extension and closes for modification
• Liskov Substitution Principle
• Subclasses should be able to replaceable by their base types without affecting existing implementation
• Interface Segregation Principle
• Many interfaces are better than one general interface
• Dependency Inversion Principle
• Depend on abstraction, not on concretions

SOLID principles are a time-tested solution for software design problems. This principle helps to achieve loosely coupled code design.

Common problems in software architecture?

• A poor architecture will develop bugs over time
• the application requires to be altered for all the customization and future extensions
• Once the application is ready and in production, over time it takes a lot of effort even for a simple task
• Creating a single class with a lot of responsibility
• Unnecessary dependency between classes
• Redundant code

Why we should use SOLID design principles?

• SOLID principles help to solve above listed common problems
• Provides loosely coupled architecture
• Classes can have their specific responsibility 
• Rather than extending the one class using inheritance and abstraction, we can achieve the reusable environment
• It stops affecting the existing functionality
• It allows focusing more on abstraction 

We will go into detail in each dedicated post. Let me know if you have any suggestions or feedback.