I don't agree with most sentences on programming that contains the words "prevent someone from".
"Classes, methods or functions should be Open for extension (new functionality) and Closed for modification. This is another beautiful object oriented design principle which prevents some-one from changing already tried and tested code."
No, no, no. Let someone modify whatever the hell they want. If they screw it up, that's on them. Quit it with this childish belief that you have to control people.
Yes, but I think the closed principle is more about providing an interface, i.e.: the interface should be closed for modification so that implementing classes or interfacing services do not have to be changed everytime you add a feature.
My girlfriend came up with a nice metaphor trying to follow along. The open/closed principle applies to natural language as an interface. It is important language can be extended to convey new meaning, but also important that it is closed for modification so we retain the ability to understand eachother.
With the exception of service APIs in which everyone is forced to use the latest version, I still don't agree. If we're talking about libraries, nobody is forcing people using the library to upgrade to the latest version (or at least shouldn't be). If you have a good reason to change the interface, change it, don't let the fact that it doesn't match previous versions of the interface prevent you from improving the product.
The open-closed principle involves creating classes that _never_ change in the future. If you want to extend their behaviour you should subclass them. This makes some sense in a codebase with no tests, the risk of change becomes too high. But then who codes without tests these days? Given that you should always be writing tests for your code I think this principle should probably be left in the history books. It seems like a great way to add unnecessary complexity to your code base.
> Let someone modify whatever the hell they want. If they screw it up, that's on them.
If changing a common component or library breaks my code, they may be at fault, but it's still my feature that breaks. The open-closed principle is about sandboxing modifications to the scenarios that need those modifications. It's not about babysitting.
Without it, when you make a change you need to consider every consumer or risk breaking their case. Or, you get these nightmarish components that have "modes" (if I'm included in this context, act like this, if I'm included in that context, act differently).
"Classes, methods or functions should be Open for extension (new functionality) and Closed for modification. This is another beautiful object oriented design principle which prevents some-one from changing already tried and tested code."
No, no, no. Let someone modify whatever the hell they want. If they screw it up, that's on them. Quit it with this childish belief that you have to control people.