Hacker News Reader

Comment by Someone1234 | Hacker News Reader

This is almost certainly a personal problem, but I can never wrap my head around the "open/closed" thing. I'm actually a big fan of the other SOLID principles and use them daily, which makes this extra awkward.

The problem with the open/closed principle is that the explanations of it start convoluted and get even more convoluted from there. With a bunch of disclaimers needing to be added to any example of an open Vs closed implementation using a modern framework/language.

Even the Wikipedia article makes no sense to me:

https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle

Now if they're just talking about immutable objects, that makes sense. But it doesn't seem that simple, and many of the examples aren't really implementing immutable objects.

View on HN

This is real handwavy and potentially wrong, but maybe helpful.

Closed is the thing you're _enforcing_. You have to pay your taxes. Open is the policy that you don't care much about. Cash, check, money order. Maybe others get tacked on later.

I know it doesn't sound like much, and it's really a pretty weak tool compared to stuff like contracts.

The best example i can dredge up is gui components. I don't care _what_ you draw. I do care that you stick to the small area of the screen set aside for you. The base component _enforces_ no coloring outside the lines. Inside the lines, you can be a textbox, or a button, or a whatever.

One way of looking at it is that it's a check on whether you're really following the single-responsibility principle (SRP).

If your unit of software (a function, a class, a module, etc.) really only does one, specific, narrowly-defined thing, then two things follow:

(1) It should be easier to get it right. Not only are you reducing the size of the problem you have to solve, you're also removing the need to keep two or more things straight in your head while you work on it. Therefore, in theory, the more you follow SRP, the more you get it right the first time and don't need to go back and fix it.

(2) There aren't multiple reasons to need to go back in and change it. Since that unit of software only had one responsibility, when needs and requirements change, then either what it does is still relevant, and you leave it unchanged, or it's not and you delete it. If you need to do something different, then you create a new unit of software that does that other thing.

Obviously these are just principles and ideals, not inviolable laws. Sometimes you go back into a closed unit of software and fix a bug because your implementation was never right in the first place.

It's not about runtime objects, its about static code that should be closed for modification. Plugin architectures are most representable thing for this I can think of: You don't need to change any code. You just write new code and extend the capability of the existing code. In this case you don't even need to recompile anything. Of course plugin architectures are the extreme.

SOLID is about how your codebase and compiled libraries change in response to changing requirements. Open/closed says that if your code is well architected, then you should be able to handle changes by using existing modules (e.g. classes or functions) in new ways (extension) instead of cracking open the source code and modifying it. If you see that one particular file is being changed in commit after commit, it is a prime candidate for refactoring to better follow the OCP.

Interpret it as closing a class from modification to maintain backward compatibility, but allowing extension through inheritance. This is common when extending a class inside a library. Apply it to the classes, not the instances.

Reply on news.ycombinator.com