Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

SOLID Principles by Examples: Open/Closed

DZone's Guide to

SOLID Principles by Examples: Open/Closed

This post analyzes and provides a real-world example of the Open/Closed principle, one of the five SOLID principles for programming.

· DevOps Zone ·
Free Resource

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

This post continues the analysis of the SOLID principles started some blog posts ago. This is the turn of the Open Closed Principle (OCP).

The Definition

"An object/entity should be open for extension but closed for modification."

What we are basically talking about is designing our modules, classes, and functions in a way so that when a new functionality is needed, we should not modify our existing code, but rather write new code that will be used by the existing code.

The Example

In this example, we're designing a class that represents the human resources department of a company and one of its main activities: hire people.

public class HumanResourceDepartment
{

    private IList<Developer> _hiredDevelopers;

    private IList<Manager> _hiredManagers;    

    public void Hire(Developer developer){ 

        developer.SignContract();
        _hiredDevelopers.Add(developer);
    }

    public void Hire(Manager manager){ 

        manager.SignContract();
        _hiredManagers.Add(manager);
    }
}

This class violates the OCP because if HR wants to hire a secretary, we have to add another Hire method and another IList where T is Secretary in addition to creating the new Secretary class. So our initial purpose to write new code that will be used by existing code hasn't been met.

Refactoring

interface IEmployee
{
    public void SignContract();
}

class Developer : IEmployee
{
    public void SignContract()
    {
       //...
    }
}

class Manager : IEmployee
{
    public void SignContract()
    {
       //...
    }
}

class Secretary : IEmployee
{
    public void SignContract()
    {
       //...
    }
}

public class HumanResourceDepartment
{

    private IList<IEmployee> _employees;

    public void Hire(IEmployee employee)
    {
        employee.SignContract();

        _employees.Add(employee);
    }
}

The HumanResorceDepartement class now respects the OCP because the new code (the Secretary class) can be used by old code (the Hire method). We did this by abstracting the concept of a manager/developer/secretary stating that they are all employees that sign a contract when they are hired. So, we created an interface called IEmployee that exposes the SignContract method.

The OCP is tightly coupled with the Single Responsibility Principle. If we design a class with SRP in mind, it is very likely that we also respect OCP or that little work is required to meet both, and vice versa.

TL;DR

The OCP makes our code more reusable and less coupled. This way we can write new code that with little impact in our existing codebase. SRP and OCP are closely related parents and their application makes our code more clean and maintainable. What's your experience with SOLID principles?

Click here for the next part of this series: Liskov Substitution Principle!

Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

Topics:
solid principles ,programming ,devops ,agile

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}