The OCP demystified
Original image by Arek Socha from Pixabay

The OCP demystified

Hey everybody,?

Nicholas here from About Coding. This is the 3rd edition of my newsletter. Due to circumstances (I moved to my new place!), I wasn’t in time to bring you a November edition. But I think this edition can make up for that! I believe I have something special.?

I have also changed the location of my newsletters. From now on, my newsletter articles will be posted on medium. I am going to be very honest about the reason for that: I spend a lot of time and effort into these newsletters as I want to bring top notch information. And even though I like writing about software design and it has become somewhat of a passion, I also want to start monetizing this as well (or at least try to). So here is the deal: all the newest articles will end up on medium and should be freely available to read until at least one week after the newsletter. If you like the content, it would be a tremendous help to follow me on medium as well.?

Now the good stuff… In this edition, I will demystify the Open/Closed Principle. What is this principle really about and how does it work? In this edition, I want to reveal all of its ‘secrets’! I think this will be a huge help in better understanding this principle and software design in general.?

The Open/Closed Principle (OCP) is the second principle in the set of SOLID principles. It says that your code should be open for extensions but closed for change. I can understand if your facial expression turned into confusion while reading that.?

The open/closed principle is promising us to be able to ‘change’ the code base by adding code but without having to change existing code. At least, that is the promise. In reality, there are most likely going to be some changes to existing code in most of the cases.

Want to know how this actually works? There is even a small example! Then check out the full article.

I am very interested in what you think about the article. It’s a longer one, and I wonder if everything is clear enough. What information did you hope to find but wasn’t included in the article? Reach out to me on LinkedIn (leave a comment or DM me, its all good). If we didn’t make a connection before, it's an excellent time to do so right now ??.?

Whenever you are ready to learn more and become more effective with software design, check out my website and subscribe to my software design course.?

Happy learning!?

#softwaredevelopment #softwareengineering #softwaredesign

Steve Bassette

Software Engineer passionate about Community Leadership

2 年

I really like OCP and I think your article treats it well. I think there's one like that stands out: "If we have an abstraction with some details that are important in our current context, we can change these details without changing the essence of our abstraction." The important piece is *our current context*. You need to moderate the level of OCP you apply. Most people's problems with the OCP stem from ignoring this sentence. People tend to abstract too soon and then over-abstract. This is the same problem as premature optimization, and similar metrics can be applied. It's also a case of YAGNI. In practice this problem shows up as abstracting a horse as * An Animal * A 4 legged animal * An object that can move * An object that eats * A vertebrate * An animal that needs oxygen Why are these abstractions negative? Although all the abstractions make sense in *some* context, what I didn't say was my example application is to manage a horse ranch. We most likely don't care about these most of these abstractions. Worse, we do care about a few others. I love the OCP, but like everything, it's best to let it evolve with your app and domain.

Kevin Kouomeu

Freelance Software Engineer

2 年

I was skeptical about Uncle Bob's description of the OCP, but your article on Medium is very clean and really helps to understand the principle. Thank you and congratulations for this work ??

要查看或添加评论,请登录

Nicholas Ocket的更多文章

  • The problem in our industry...

    The problem in our industry...

    Hey everybody! Here is the Februari edition of the About Coding newsletter. We have a problem in our industry.

  • TDD is not software design

    TDD is not software design

    Hey everybody! The About Coding newsletter is back with a first edition of 2025. Last year, I was really busy creating…

    17 条评论
  • Lean Architecture

    Lean Architecture

    Technology seems to evolve every day, but the way we build software doesn’t seem to evolve at the same rate. On the…

    10 条评论
  • Rich Domain Models

    Rich Domain Models

    Hey everybody! This is the October 2023 edition of my newsletter. In my previous edition, I talked about how an open…

    1 条评论
  • Your own superpower

    Your own superpower

    Hey everybody! This is the September 2023 edition of my newsletter. A bit late again (as it is October already), but I…

    8 条评论
  • Clean Architecture: the essence of the dependency rule

    Clean Architecture: the essence of the dependency rule

    Hey everybody! This is the July 2023 edition of my newsletter. A bit late again, but the work doesn’t stop really.

    5 条评论
  • Change in Clean Architecture

    Change in Clean Architecture

    Hey everybody! This is the June 2023 edition of my newsletter. A bit late, but I had a tremendous amount of work the…

    3 条评论
  • Coupling and cohesion

    Coupling and cohesion

    Hey everybody, Here is the May 2023 edition of my monthly newsletter! In my previous newsletter, I talked about Clean…

    7 条评论
  • Growing towards Clean Architecture: 3 common mistakes

    Growing towards Clean Architecture: 3 common mistakes

    Hey everybody, Here is the April 2023 edition of my monthly newsletter! In my previous newsletter I wrote about a…

  • From problem to code: a simple strategy

    From problem to code: a simple strategy

    Hey everybody. Here is the March 2023 edition of my monthly newsletter! Do you ever find yourself staring at a blank…

    7 条评论

社区洞察

其他会员也浏览了