Open-Closed Precept: The Exhausting Elements | by Mohamed Mayallo | Sep, 2022

The Open-Closed Precept is the second precept of SOLID. Let’s know what OCP is, its limitations, and the way can we comply with it accurately

SOLID ideas are a set of ideas set by Robert C.Martin (Uncle Bob). The principle objective of those ideas is to design software program that’s straightforward to keep up, take a look at, perceive, and prolong.

These ideas are:

After introducing the Single Accountability Precept in a earlier article, on this article, we are going to focus on the Open-Closed Precept the second precept in SOLID.

Earlier than diving into this precept, let’s agree on one thing. I imagine you agree with me that software program design isn’t an easy course of and the primary attribute of any software program is its mutability nature over its lifetime.

If we knew that upfront, I believe the primary objective we have to obtain is constructing software program in a means that accommodates this mutability and minimizes the probabilities to introduce new bugs on account of altering enterprise necessities.

In actual fact, the phrase SOFT_WARE guarantees that any software program ought to be versatile and mutable. So, software program ought to comply with some confirmed design ideas so as to obtain this promise, one among them is the Open-Closed Precept (OCP).

The Open-Closed Precept is accountable for the “O” within the SOLID ideas. Robert C. Martin thought-about this precept “crucial precept of object-oriented design.” Nonetheless, he wasn’t the primary one who outlined it. Initially, Bertrand Meyer wrote about it in 1988 in his e book Object-Oriented Software program Building. He acknowledged it as:

“Software program entities (courses, modules, features, and so on.) ought to be open for extension however closed for modification.”

However what does that imply? Merely, it signifies that if your online business necessities change you shouldn’t modify the present code (Closed for Modifications). As an alternative, you need to add a brand new code that extends the present code with out affecting it (Open for Extension).

Because of this, the ultimate entity that’s complied with this precept would have two options:

• Steady: As this entity is closed for modifications, its habits doesn’t change and it’s well-defined. In order that there are not any unintended effects on the code that consumes this entity.
• Versatile: As this entity is open for extensions, you’ll be able to add new functionalities with out affecting the present code.

If you happen to’re studying about this precept for the primary time, you would possibly suppose that there’s a contradiction. How software program ought to be closed for modifications and open for extensions on the identical time?

Effectively, to make clear this level, let’s introduce the Plugin Structure.

In his article, Uncle Bob stated:

“Plugin programs are the last word consummation, the apotheosis, of the Open-Closed Precept”

However what’s making the Plugin Structure so particular? Consider it, in case your system is constructed of some plugins which might be plugged or unplugged simply with out affecting one another. Each plugin does one single accountability and does it very properly. The system is aware of nothing about any new plugin that should prolong it. As an alternative, this new plugin simply has to satisfy the system contract. Which means including or eradicating a plugin doesn’t influence the present code in any respect.

Sure, as you would possibly suppose, the OCP and SRP are in some way related with one another.

Let me cite what Uncle Bob stated to emphasise how highly effective is the plugin structure:

“What if the design of your programs was primarily based round plugins, like Vim, Emacs, Minecraft, or Eclipse? What in the event you may plug within the Database, or the GUI? What in the event you may plug in new options, and unplug previous ones?

What if the habits of your system was largely managed by the configuration of its plugins? What energy would that offer you?

How straightforward would it not be so as to add new options, new person interfaces, or new machine/machine interfaces? How straightforward would it not be so as to add, or take away, SOA? How straightforward would it not be so as to add or take away REST?”

Effectively, that’s fascinating, isn’t it?

I imagine that you just suppose like me after I studied this precept: Actually! that’s fascinating. If we are able to obtain this precept in our design or constructing any system primarily based on plugins, there are not any points or breaking modifications we’d face sooner or later.

However suppose once more, what would you do if it’s essential to add a brand new function to your class? Sometimes, the very first thing you often do is open this class and add your function, which could be very affordable normally.

Check out this instance:

When you have the earlier instance, and your supervisor asks you to take away the tax. What’s the very first thing you’re going to do? That’s apparent.

So, does it make sense to you so as to add/take away new/previous performance with out touching the present code? The quick reply is sure, nevertheless it isn’t so simple as you suppose. Let’s proceed.

I believe that the OCP is essentially the most misunderstood among the many 5 SOLID ideas. Nonetheless, in the event you apply it accurately in your design, will probably be essentially the most useful than the others.

Presumably, you would possibly learn the definition of this precept after which ask your self, how can I apply it accurately? what are the steps that I’ve to comply with to satisfy it?

1. Sadly, there is no such thing as a one technique to write code that by no means must be modified and all the time be open to being prolonged. The one class that could be by no means modified in any respect is one thing like that:

It’s possible you’ll discover that this class is excessive in abstraction. This class has no performance by itself and 100% of its performance is handed into it, so it would by no means should be modified.

Alternatively, check out this instance under:

Clearly, this class is excessive in concreteness. This class does one factor in precisely a technique and if you wish to change its performance, it’s important to modify it directedly.

Really, any helpful code should lie between the 2 extremes. It needs to be partially concrete to attain its performance and, if wanted, partially abstracted to be reused or maintained simply.

Because of this, by no means get the extremist concept that your code mustn’t be modified solely prolonged. And consider, that both the intense in abstraction or the intense in concreteness each have their value. So, the laborious level right here is defining the correct stage of abstraction and defining the balanced level between the extremes.

One potential technique to establish this level is to begin by being concrete, besides you made positive you want abstraction 100%, and see how the applying evolves over time. When modifications are wanted, simply make them within the current code concretely for the primary time or two. Nonetheless, by the third time, it could be an indicator that the software program is prone to proceed to vary on this method sooner or later. So you need to take into consideration refactoring your code to comply with the OCP and offering the wanted abstraction.

In my view, the OCP doesn’t inform you to summary all the things to get the last word common design, as a result of, that’s unattainable. As an alternative, you probably have sturdy causes for abstraction, merely, do it, and in the event you haven’t, merely, don’t do it. The concrete design is ok till it isn’t. Keep in mind the KISS precept.

So, inevitably, you would possibly want to switch your current code or much more, your abstraction.

2. One other level you’ve gotten to remember is coping with bugs. What would you do in case your class has a bug? would you forcibly prolong it and depart a legacy code having a bug to blindly fulfill the OCP? or would you merely open your class and modify this bug immediately? So I imagine that fixing bugs ought to be an exception to the OCP.

3. We want to have the ability to predict the place the variation in our code is and apply the abstraction round it. On the identical time, we don’t wish to develop software program with an excessive amount of complexity upfront that’s attempting to guess each potential means that it may need to be modified sooner or later. So, prediction is the important thing, and on the identical time, the toughest to satisfy this precept. A extra concise technique to comply with the OCP is by introducing the Level of Variation (PV) precept that states:

Determine factors of predicted variation and create a secure interface round them.

However watch out when predicting your variations. The prices of incorrectly predicting variations will be excessive:

• If you happen to predict variation that gained’t range, you ultimately would waste your effort on over-engineering.
• If you happen to don’t predict variation that can be truly wanted, you ultimately would want to switch plenty of current code.

So, the underside line concerning this level is the next:

• Don’t summary issues simply since you predict that you just want them. Understand that creating and sustaining abstraction has its value. But when upfront, you made positive 100% that you’ll want it, go forward.
• You aren’t alleged to predict each single variation in your software program, nonetheless, it’s your accountability to outline the purpose of variations in your software program.
• As soon as the necessity for variation turns into actual, that’s the time to refactor your code and supply the correct abstraction if you really want it.

I’ve tried to simplify the earlier part as I can, however in case you misplaced, listed below are the sensible methods to comply with the OCP:

1. If you happen to can’t predict the factors of variation in your software program upfront, merely, begin concrete and easy. Then, because the software program evolves, begin your refactoring and constructing the correct abstraction round these factors.
2. If you happen to made positive 100% in your prediction concerning the factors of variation upfront, attempt to establish the correct stage of abstraction your software program want with out overcomplicating issues.

After introducing the OCP in concept and its limitations, let’s leap into sensible examples to see how can we apply the OCP in our code.

Let’s begin with this concrete instance, and attempt to refactor it with the OCP in thoughts.

This method is the only and essentially the most intuitive technique to apply the OCP and on the identical time, the perfect selection in Practical Programming.

Merely, on this method, by passing arguments to a perform, for instance, we are able to change its performance. This perform can be open for extensions by altering its arguments.

Let’s refactor the above instance by making use of the OCP and maintain this method in thoughts:

Now, as you see, this perform can print any message as a substitute of only a fastened one. So this perform is opened for extensions by altering the message it prints.

As we stated, the OCP was first utilized by Bertrand Meyer in his e book “ Object-Oriented Software program Building.” In actual fact, Meyer’s authentic method was to make use of inheritance as a core mechanism to use the OCP.

Every time your class must be modified, as a substitute of modifying the present performance, this method encourages you to create a brand new subclass that holds the brand new implementation or overrides the unique one as required. And depart the unique implementation unchanged.

Let’s refactor our instance and maintain this method in thoughts:

As you see, as a substitute of modifying the unique class Logger, we have now simply added a brand new subclass AnotherLogger that overrides the mother or father class habits which is the log technique.

As a aspect observe, you need to keep away from utilizing inheritance if potential, as a result of inheritance introduces tight coupling if the subclasses depend upon the implementation particulars of their mother or father class. If the mother or father class modifications, it might have an effect on the subclasses they usually might should be modified as properly.

Perhaps, you heard earlier than about “ Program to interfaces, not implementations” or “Composition over inheritance,” didn’t you? Due to inheritance limitations, Robert C. Martin redefines the OCP to make use of composition and interfaces as a substitute of Meyer’s inheritance. However how can we use it?

On this method, as a substitute of setting your new performance immediately in the primary class, you progress it to a different class after which reference this new class into the primary class by Dependency Injection. And any injected class should implement an interface. As soon as the brand new class implements this interface accurately, the primary class can ultimately use its performance. That’s how are you going to use composition and interfaces over the inheritance.

Let’s leap into our instance and apply the composition utilizing interfaces:

As you see, now the Logger class is impartial of any entity. Solely the injected occasion has to implement the ILogger interface. So you need to use AnotherLogger or any logger you need so long as it implements the ILogger interface.

The principle good thing about this method is reaching Polymorphism which in flip achieves the Unfastened Coupling.

Whereas, programming to interfaces introduces a brand new layer of abstraction. The interface itself is taken into account to be closed not the implementation as a result of there could be many alternative implementations of 1 interface on the identical time. The interface itself is reused not the implementation. Which in flip, results in free coupling.

The technique design sample is a good instance that achieves the OCP in a chic means. It is likely one of the most helpful design patterns. It’s primarily primarily based on programming to interfaces. Let’s see the way it works.

You’ve gotten an issue that may be solved in a number of methods. These methods are referred to as Methods, and each technique encapsulates a special answer for the issue. All these methods should implement one interface to unravel this drawback. This drawback is in a category referred to as Context. These methods will be injected into the context in some ways like Dependency Injection, Manufacturing facility Design Sample, or just, by If Situation. Check out this diagram:

Now, your code is open for extensions because it lets you use completely different methods so long as they implement the required interface. And closed for modifications as a result of the context class itself doesn’t must be modified, it solves its drawback with any technique, it doesn’t matter what precisely the technique is.

I wrote an article earlier than concerning the Technique sample, you’ll be able to test it out right here.

After this clarification, I believe you’ve gotten an concept about the advantages of making use of OCP in your code. Let’s summarize a few of them:

1. When you have a package deal that’s consumed by many customers, you can provide them the power to increase the package deal with out modifying it. In flip, that reduces the variety of deployments which minimizes the breaking modifications.
2. The much less you modify the present code, the much less it might introduce new bugs.
3. The code turns into less complicated, much less advanced, and extra comprehensible. Have a look at the Technique sample within the part above.
4. Including your new performance to a brand new class lets you design it completely from scratch with out polluting or making workarounds within the current code.
5. As a result of the brand new class relies on nothing, you simply want to check it not all the present code.
6. Touching the present code in legacy codes will be extraordinarily tense, so including new performance in a brand new class mitigates that stress.
7. Any new class you create is following the Single Accountability Precept.
8. It lets you modularize your code completely, which in flip, saves time and price.

After introducing the Single Accountability Precept, the primary SOLID precept, in an earlier article, we have now mentioned the second precept, the Open Closed Precept, on this one.

As we noticed, this precept is likely one of the most vital design ideas. Following it allows you to create modular, maintainable, readable, easy-to-use, and testable purposes.

Though the advantages you achieve from making use of this precept, it isn’t straightforward to use it. There is no such thing as a one technique to apply it, it’s unattainable to foretell each single level of variations upfront, and it’s laborious to outline the correct stage of abstraction your software actually wants.

On high of that, we launched a sensible technique to comply with this precept. Firstly, remedy your drawback utilizing easy concrete code. Don’t summary all the things upfront. Secondly, attempt to establish the purpose of variations in your software. When you have a function that regularly modifications, it could be a degree of variation. Lastly, you probably have recognized these factors, you need to doubtless take into consideration OCP, modify your code and attempt to make it extensible as you’ll be able to for future wants.

Lastly, we have now launched three ways in which allow you to use the OCP and knew that the really helpful means is utilizing Composition and Interfaces.

If you happen to discovered this text helpful, try these articles as properly:

Thanks loads for staying with me up until this level. I hope you take pleasure in studying this text.