OCP : Open Closed Principle

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

Contents hide

1 Previous articles

2 What is The Single Responsibility Principle?

3 Things to consider

4 Approaches

5 Plugging and Middleware

6 Where to apply this principle?

7 Some heuristics and compromises

8 Conclusion

What is The Single Responsibility Principle?

What is The Open Closed Principle_ — What is The Open Closed Principle

Open closed principle, software organizations (classes, modules, functions, etc.) have to open for extension but closed for modification. This basically it means that such an organization has the ability to allow prolonging its behavior without changing 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 adds new features using it as a parent. Once a descendant class is defined, there is no need to modify the original or interrupt its clients.

The general idea of this principle is excellent. It tells you to write your own code, which allows you to add new functionality without changing the existing code. This prevents you from having to adapt to all the classes you need for a change in one of your classes.
This principle states that software companies should need to open for extensions but closed for modifications.

Ensure that this condition is positive for the following factors:

This will prevent changes or extensions from one module, changes to other modules, more work by the developer, and some modules from being unnecessarily rebuilt and re-tested.
In addition to greatly facilitating the change of business rules in an application. This will also prevent some new bugs and issues, as the extension will not lead to modification of other modules.

Things to consider

This is where this particular principle of Open Closing comes into play. When the time comes, you need to confirm where to change the existing code:

Keep current tasks, classes, modules as they are or at least close to what they used to – unchangeable.
Expand existing classes, functions, or modules that can be integrated (avoid inheritance), then reveal a new feature or functionality under another name.
Abstractions in general (using Swift’s protocol) will solve the problem of OCP breach of credit.
In general, Enoms is going to disrespect OCP, so you need to very careful about its use. When it is concluded that it is really necessary to use this structure, it is recommended to focus on switch-case simulation using all those instances. When an extension is needed, this is done to prevent changes to many pieces of code throughout the application.
The modification code cannot 100% closed, so the best thing to do is try to measure the major variable axes and close the code for these axes.
The use of personal variables in classes is an antidote to this principle and is also useful to respect. The same is true for heuristics who say not to use global variables.

Approaches

A more modern approach is to use a composition or integrated design pattern.
The most strategic part is having a good idea of what changes will happen in the future, with your abstractions being more resilient to changing needs without having to rewrite the code.
In such a case it is really helpful to have regular scope meetings where you or your team can discuss future items or business needs ahead of time to present a design plan for your system modules.
The more you know the better. As an engineer, you do not like many surprises faster than activating an efficient and reliable system in a short time. You are often going to cut corners.
This means that we should always try to write code that should not change whenever needs change. All new functionality that can add by adding new composite classes or methods or by reusing existing code through agents.

Plugging and Middleware

The open-closed principle also applies to plugins and middleware architecture. In that case, your basic software is the basic functionality of your application.
In the case of plugins, there is a basic or basic module that you can combine with new features. And functionality through a common portal interface. A good example of this is web browsers like Chrome.
For example, in the case of middleware, you have a demand-response cycle. And you can add intermediate business logic to your application for additional service or cross-cutting issues.

Where to apply this principle?

This principle will help us to protect ourselves from change. That means we have to apply it to every class. In practice, it has no ability to do considering the time and effort it takes.
Instead, we need to identify places where an application is likely to change. Apply this principle only in those cases. There are two ways to identify these differences, one based on your previous experience and the other based on user feedback. By following agile methods we can get continuous feedback from the user. And with it we can implement it wherever we want. This is a continuous process and will evolve over time.

Some heuristics and compromises

There are some principles and conventions arose because of this very principle. Two of them will mention briefly:
Personalize all variables in the class and do not use global variables. It is assumed here that it is not worth going into more detail to avoid escaping the main subject of the article.
In short, personalizing all the attributes of a class helps to respect the OCP, as it ensures that other classes do not unnecessarily access those attributes. Extensions of this class ensure that those properties do not imply changes in other classes that can use. In Object-Oriented Design we call this circulation.
Also, another point to note here is that the private existence of the property allows for better control over all the states of the class. For example, if a property is public, this allows other classes to use and change its status at any time, as well as what can cause unpredictable behavior throughout the entire application, as well as the need to deal with concurrency and ensure atomization.

Speaking of not using global variables and the argument is actually closer to the previous argument. Any module that relies on a global variable that can not be considered closed because any other module can use this variable and change its status. The negative effect here is the same as mentioned earlier, the need to change classes that use this global variable when unexpected behavior and some extension is needed.

Finally, it is important to note that these conventions should not be taken lightly, as they’re sometimes occasions when it makes sense to publicize a variable or even use global variables. This article presents only a few arguments that are valid in most cases but not necessarily a rule. It is always up to the developer to try to analyze and measure the main advantages and disadvantages of each approach.

Conclusion

This principle is considered to be at the heart of Object-Oriented Design, and its importance can be seen primarily in poorly designed large-scale projects where a simple change can cause a number of problems and errors that are extremely difficult or sometimes impossible to implement.
Thanks for reading the article Open Closed Principle as an essential component in System design and architecture.

My articles on medium