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

Discover how quick and easy it is to secure secrets, so you can get back to doing what you love. Try Conjur, a free open source security service for developers.

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!

Conjur is a free open source security service built by DevOps engineers. With integrations with all your favorite tools and an easy way to secure secrets, it's a no brainer. Come check it out!

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