OCP: Open Closed Principle

Introduction

This is the 9th article in the System Design and Software Architecture series. In this article, we are discussing the sub-topic of the design principle, OCP: Open Closed Principle.

What is The Open Closed Principle?

The Open Closed Principle states that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. This means that such an entity should allow its behavior to be extended without altering its source code. A class is closed because it is compiled, stored in a library, baselined, and used by client classes. It is also open as any new class can add new features using it as a parent. Once a descendant class is defined, there is no need to modify the original class or disrupt its clients.

The general idea of this principle is excellent. It tells you to write code that allows you to add new functionality without changing existing code. This prevents the need to modify all the classes that depend on the one being changed. This principle states that software entities should be open for extension but closed for modifications.

Ensure Positive Impact

Ensuring adherence to this principle provides the following benefits:

• Prevent changes or extensions from one module from affecting other modules, reducing work for developers, and avoiding unnecessary rebuilding and re-testing.
• Facilitate changes to business rules in an application without causing new bugs and issues, as extensions do not require modifications to other modules.

Things to Consider

This is where the Open Closed Principle comes into play. When it’s time to change existing code, consider the following:

• Keep current tasks, classes, and modules as they are, or at least close to their original state — unchangeable.
• Expand existing classes, functions, or modules that can be integrated (avoid inheritance), then reveal new features or functionality under another name.
• Abstractions in general (using protocols) will solve the problem of OCP breaches.
• Be cautious with enums, as they generally violate OCP. When necessary, focus on switch-case simulation using all instances to prevent changes to multiple pieces of code throughout the application.
• Modification code cannot be 100% closed, so try to measure the main variable axes and close the code for these axes.
• The use of private variables in classes respects this principle and prevents unnecessary access by other classes. The same goes for the heuristic against global variables.

Approaches

• Use a composition or integrated design pattern.
• Understand future changes to make abstractions resilient to changing needs without rewriting code.
• Hold regular scope meetings to discuss future items or business needs ahead of time to present a design plan for system modules.
• Write code that doesn’t change when requirements change. Add new functionality by adding new composite classes or methods or reusing existing code through agents.

Plugging and Middleware

The Open Closed Principle also applies to plugins and middleware architecture. In the case of plugins, there is a core module that can be extended with new features and functionality through a common interface. A good example is web browsers like Chrome.

In the case of middleware, you have a request-response cycle, and you can add intermediate business logic for additional services or cross-cutting concerns.

Where to Apply This Principle?

This principle helps protect against change. It doesn’t mean applying it to every class, but identifying places where changes are likely and applying the principle there. This can be done based on past experience and user feedback. Agile methods can help by providing continuous feedback, allowing for implementation wherever needed. This is a continuous process that will evolve over time.

Heuristics and Compromises

Some principles and conventions arise from this principle. Two key points include:

• Personalize all variables in a class and avoid global variables. This respects OCP by ensuring other classes do not unnecessarily access attributes. Extensions ensure properties do not imply changes in other classes.
• Private properties allow for better control over class states. Public properties allow other classes to change their status at any time, causing unpredictable behavior and concurrency issues.

Not using global variables is closer to the previous argument. Any module relying on a global variable cannot be considered closed because any other module can change its status. This leads to unexpected behavior and the need to change classes when an extension is needed.

While conventions should not be taken lightly, there are occasions when it makes sense to publicize a variable or use global variables. Each approach has advantages and disadvantages, and it’s up to the developer to analyze and measure them.

Conclusion

This principle is central to Object-Oriented Design, especially in large-scale projects where a simple change can cause numerous problems. Thanks for reading the article on the Open Closed Principle as an essential component in system design and architecture.

Originally published at https://onloadcode.com on March 21, 2021.