SOLID - OCP - Everything You Should Know About the Open-Closed Principle

The Open-Closed Principle (OCP) was defined in 1988 by Bertrand Meyer. It states that a software element should be open to extension but closed to modification.

Thanks to the open-closed principle, our systems can be backwards compatible. This rule is especially important if we want to create systems that will have more than one version. If we focus on this principle, when releasing subsequent versions, we will not spoil the previous ones. If we introduce changes that generate a lot of errors in dependent modules, it is a sign that we are probably not following the open-closed principle.

SOLID - OCP - Everything You Should Know About the Open-Closed Principle

Code #1 not following the open-closed principle:

public enum LogType
{
    File, Database
}

public class Logger
{
    private readonly LogType _logType;

    public Logger(LogType logType)
    {
        _logType = logType;
    }

    public void Log(string message)
    {
        switch (_logType)
        {
            case LogType.File:
                throw new NotImplementedException();
            case LogType.Database:
                throw new NotImplementedException();
            default:
                throw new Exception("Unexpected log type!");
        }
    }
}

An enumeration type has been created - enum, which is passed when creating a new instance of the Logger class. In the Log method, based on the logger type, we determine where the message is actually logged.

For the purposes of this example, we don't need an implementation of what logging in actually looks like. Everything seems fine, we pass the argument and depending on whether we want to save the message in a text file or in the database, this actually happens. However, the Log method does not satisfy the OCP policy because it cannot be closed to new log types. Now, if you wanted to add, for example, logging messages to Excel, you would have to add a new type and change the Log method and add another statement to the switch. This example is quite simple, but what if there were more methods in this class whose operation depended on the logger type - then there would be even more changes.

How can you write this class according to the OCP rule? You have to rely on abstraction.

Code #1 using the open-closed principle:

public interface IMessageLogger
{
    void Log(string message);
}

public class FileLogger : IMessageLogger
{
    public void Log(string message)
    {
        throw new NotImplementedException();
    }
}

public class DatabaseLogger : IMessageLogger
{
    public void Log(string message)
    {
        throw new NotImplementedException();
    }
}

public class Logger
{
    private readonly IMessageLogger _messageLogger;

    public Logger(IMessageLogger messageLogger)
    {
        _messageLogger = messageLogger;
    }

    public void Log(string message)
    {
        _messageLogger.Log(message);
    }
}

As you can see in the example above, all types are classes that implement the IMessageLogger interface. Thanks to this, if we now need to add a new login type, we just need to create a new class that will implement this interface. The Logger class itself does not require any changes. The class meets the OCP assumptions.

Let's move on to the next example. This time we are to create a class for sending SMS, which is to send SMS using the API issued by the smsapi service.

Code #2 not following the open-closed principle:

public class SmsSender
{
    private SmsApiService _smsApiService;
    public SmsSender(SmsApiService smsApiService)
    {
        _smsApiService = smsApiService;
    }

    public void Send(Sms sms)
    {
        _smsApiService.Send(sms);
    }
}

The above SmsSender class has been designed in such a way that it requires providing an instance of the SmsApiService class and based on this argument, the SMS is sent. The code works properly, it was implemented in the dll. Other developers have started using this class, they have a lot of calls in their applications. One day, without going into details, they came to the conclusion to replace the SMS API with SMS Server.

The developer had to make changes to the SmsSender class and changed it to the following.

public class SmsSender
{
    private SerwerSmsService _serwerSmsService;
    public SmsSender(SerwerSmsService serwerSmsService)
    {
        _serwerSmsService= serwerSmsService;
    }

    public void Send(Sms sms)
    {
        _serwerSmsService.Send(sms);
    }
}

Then he released another version of his dll. Unfortunately, after updating, consumers of this dll received compilation errors every time this class was called, because the constructor now accepts an object of the SerwerSmsService class, and not SmsApiService as before. This happened because the open-closed rule was not applied here. What should the initial code of this class look like in this case?

Code #2 using the open-closed principle:

public class SmsSender
{
    private ISmsService _smsService;
    public SmsSender(ISmsService smsService)
    {
        _smsService = smsService;
    }

    public void Send(Sms sms)
    {
        _smsService.Send(sms);
    }
}

Having such a class, if you want to change the SMS sending service provider, just add a class implementing the ISmsService interface and the SmsSender class will not be changed in any way. Consumers of this library do not need to change their calls to this class. After the update, our library is still backwards compatible.

SUMMARY