Solid principles: 2. Open-closed principle


The second SOLID principle, open-closed, ie open to extension, closed to modifications. What is going on? About this further.

This rule says that the class and its modules must remain open for expansion, i.e. you can add new methods and functionalities, but with this expansion you can not modify anything in existing modules, change their activities because it would be breaking this rule.

Modification of the class is strictly prohibited, because the change in the operation of existing classes may affect the operation of others, which will disturb the operation of the whole system and will disintegrate. A good solution does not create further problems.

This rule is especially important in large projects, for the creators of all extensions, plugins and programming libraries.

For sure, each of you had to change the class along with the changing requirements of the application. Thanks to this principle, your project will be flexible and easy to expand.

While sticking to the first SOLID principle, we must also stick to the second, so let’s move to practice.

In our store logic according to the second SOLID principle, this piece of code is bad:

Why? Let’s add a new type of product, eg fruit, so now it will look like

We had to change the CheckTypeProducts method and add a new variable and another method, so we violated the open-closed SOLID principle, polymorphism and inheritance are often good in such situations.

Correctly, it should look like this:

Efficiently using polymorphism and inheritance, we took care of the correctness of the open-closed principle, now if we would like to add some type of product again, it would be enough to add a new class and we would not have to change nothing in existing classes and methods.

However, one more thing is wrong here – the constructor in the Client class, we do not want to add new arguments to it, new variables, moreover, if such a constructor had 50 arguments, it would look … in a word … tragic and illegible, readable constructor together with the rest of the code it should look like this:

As you can see now adding arguments in the constructor does not fully comply with the open-closed principle because we have to adding new variables anyway, but it still looks better than the previous constructor. Of course, there is also something like Builder Fluent Interface, which allows you to write the constructor even more readily, but later about it, as we will discuss the Builder design pattern.

Finally, the call in the Main method:

Result:

 

Summary

And that’s all about the open-closed principle, I hope you have seen how useful it is, the importance of it increases the flexibility, the ease of expansion and reduces the number of bugs in the future expansion of the project.

Link to github with the whole code from this article: https://github.com/Slaw145/Open-Closed-principle

This content also you can find on my steemit blog  https://steemit.com/solid/@slawas/solid-principles-2-open-closed-principle

And on medium: https://medium.com/@sawomirkowalski/solid-principles-2-open-closed-principle-c62ab0117a7c

As a standard, I remind you about the newsletter, which I send notifications about new entries and additional information about the IT world in general.🙂

And NECESSERILY join the DevmanCommunity community on fb, part of the community is in one place 🙂

– site on fb: Devman.pl-Sławomir Kowalski

– group on fb: DevmanCommunity

Ask, comment underneath at the end of the post, share it, rate it, whatever you want🙂.

 
If that post was useful for you share it with your friends :)

Post a comment

Be first!

avatar
  Subscribe  
Notify about