What is the Open-Closed Principle(OCP) and why should we care

Imagine the following scenario.

You found a job at a small IT consultancy firm and had just started your first day at work. Your boss walks up to you with a list of features to be implemented into an existing messaging system. As this is your first day at work, you decide to work on the simplest feature on the list, which is to add support for attaching videos, stickers, documents, images and voice recordings.

As you had previously implemented a text messaging system as a side project, this seems like an easy task. You happily pull the relevant repository and start exploring the project. However, you soon realise that it isn’t as easy as it initially seems. Since there exists a Text class that the Chat component depends on, if we were to adhere to the current design, asides from adding new classes for the different components, we require changes to be made to the Chat component which facilitates the sending of the various messaging components. This proved to be a tedious task since you have to make the change for every messaging component.

Below is the illustration of how the implementation would look like in this scenario. Note that we will leave out details of how the Chat component interprets and appends the message for brevity in this example.

Figure 1. Adding messaging components without Open-Close Principle.

If this scenario doesn’t sound familiar to you, rejoice! You are about to save yourself(and your colleagues) some precious time by applying a design principle formally known as the Open-Closed Principle by Bertrand Meyer.

The Open-Closed Principle(OCP)

The Open-Closed Principle which is one of the design principles of SOLID, states that “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”. In simple terms, this means that a component should be easily extensible and should not be unnecessarily modified.

So how do we know when a component can be modified?

Well, the simple answer to this is to only modify the component when it is absolutely necessary. In the example above, although the system works, there is still room for improvement to prevent changes being a made to the Chat class every time a new messaging component is introduced.

Consider the following design that utilises OCP instead,

Figure 2. Adding messaging components with Open-Close Principle.

It is easy to see that adding a new messaging component will not need any changes to be made to the Chat class since we can simply implement the Message interface thus, extending the component instead. The only time that we might have to make a change to the Chat class is when we want to extend it’s functionality e.g implementing Voice or Video chat.

Pros and Cons

Let us now review some pros and cons related to applying the Open-Close Principle.

Pros

• Components are easier to extend
• Decreases coupling
• Reduces future maintenance cost

Cons

• Additional interfaces/classes have to be added
• Can be costly to implement on existing systems

From the example above, we can see that by introducing a Message interface, it made it easier for the related components to easily extend the messaging functionality. Furthermore, as we depend on the interface instead of every concrete class, we decrease the coupling between the Chat component and the various messaging components since the number of dependencies is reduced. As such, this creates flexibility to changes as adding a new type of message will not require a change in the Chat component.

However, asides from these advantages, we must always keep in mind the associated costs that come with it. From the example above, to refactor the components to adopt OCP, it required us to modify the existing Chat component and the different messaging components. Therefore, imagine a system consisting of a hundred different components that did not follow OCP initially. The cost of having to change these components will be huge.

As such, adhering to this principle when adding a new component may be more beneficial as compared to implementing it onto an existing component.

Summary

By applying this principle, it increases the maintainability and reusability of our code making it easier for us(and our colleagues) to extend the component in the future.

Do note that although the Open-Close Principle might fit most situations, there may be exceptional cases where such a principle will not add much value to the project i.e components that are guaranteed to not have any new additions during its lifetime.