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

Is the concept of adopting a continuous everything model a daunting task for your fast moving business? Read this whitepaper to break down and understand one of the key pillars of this model in Continuous Governance: The Guardrails for Continuous Everything.

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!

Are you looking for greater insight into your software development value stream? Check out this whitepaper: DevOps Performance: The Importance of Measuring Throughput and Stability to see how CloudBees DevOptics can give you the visibility to improve your continuous delivery process.

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