Better programming: The Open/Closed Principle

In this series of articles you will become familiar with the SOLID principles, which will help you write more modular, understandable, and maintainable code. SOLID is an acronym that encompasses the following principles:

• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

In this article we will explore the second of these principles, called the Open/Closed Principle. This principle states that the classes and modules in our code should be open for extension but closed for modification. This allows the software to evolve without breaking existing functionality.

To learn Python and build the skills to land your first job, check out our Professional Python Developer Bootcamp.

How to apply the Open/Closed Principle

The open/closed principle states that we should be able to extend the capabilities of our code by adding new functionality, but without having to modify the codebase that already exists.

By designing our code with this principle in mind, we will avoid major rewrites whenever we have to include new functionality in our apps. The code that has already been tested stays there, and the new code is written alongside it.

The key to applying this principle effectively is keeping a global vision of the project while implementing a feature. We must think about how the code we are writing right now will impact the implementation of other features.

Let’s look at a concrete example applying the open/closed principle. Let's continue with the streaming app example that we used in the previous article:

Suppose we are developing an app to play songs in different formats. Initially, our player only supports MP3 files. The code could look like this:

Suppose we are developing a music player app. For the moment, our app will only play .mp3 files. So we could implement a music player class in our application as follows:

This code is correct. However, what will happen in the future if you want to support new file formats? We will have to modify this code (and risk breaking it) in order to add the new functionality.

To solve it, we can plan ahead and accommodate new file formats from the get-go:

In this design, we implement the MusicPlayer class to be compatible with different audio formats. Now, to add an extra audio format, we can extend our code including a new class for it. We do not need to modify the previous code.

The Benefits of the Open/Closed Principle

By using the Open/Closed Principle, you get the following benefits:

Reduce Risk of Errors

By limiting modifications to existing and already tested code, you will significantly reduce the probability of introducing unforeseen errors that could compromise current functionality.

Improve Readability

Code that follows this principle is usually better designed and less improvised, which makes it easier for other programmers to understand and contribute to.

Facilitate Maintenance

The Open/Closed Principle makes your code more stable and better laid out, so it will be easier for your colleagues to locate a particular feature in it.

Promote Reusability

Well defined, stable code with clear responsibilities facilitates the reusability of your functions, classes and modules in different parts of your project.