Say "No" to the Open/Closed pattern

The open closed principle is just a result of a deeper "law", Conway's Law:

"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"-- Melvin Conway ( http://en.wikipedia.org/wiki/Conway's_law)

Entities should be closed to modification by parties not responsible to maintaining the code. Extension interfaces are used to rationalize the interdepartmental dependencies in a streamlined way that lowers the communications overhead of coordination, negotiation, and control.

That is pluggability reduces having to sit through meetings with agonizing coworkers and being closed avoids having to yell at Bob from three floors down who just borked your code base.

But anyway the bottom line is that the open closed principle is not a principle but merely one common view of organizational design reflected in code architecture.

Conway's law is more important because it is more predictive and more powerful. You can refactor code or the human organization or the communication between people.

I agree that the subclassing idea is a particularly bad one. For starters, to subclass a class to be able to change it without changing the code is almost certainly going to break liskov's substitution principle because most likely your change is not going to be exactly functionally equivalent to whatever the class really does.

I have worked on a couple of codebases with deep and complicated inheritance trees and it has convinced me that inheritance is a bad idea for code sharing and only really helpful for times when there is a clear case for polymorphism. Mostly in those cases an interface works as well as a base class.

Still I don't think the open close principle is completely worthless. I've also seen pieces of code that tend to change a lot (not might change, but actually have changed) where new behaviour is constantly added in new if statements. Validation logic is generally a good example of this. I think in this case, being able to inject in new behaviour using an interface is much preferable to adding another branch to an if statement.

The strength of Uncle bob's advice tends to be that it's very practical and explicit, which makes it quite accessible to the people who need it most: programmers without much experience. It's kind of a pity that this advice is so wooly and that it's presented as subclassing (which is super bad advice), missing the actual good advice that code is easier to write rather than to change, which I think is true even in a system with unit tests.

Just emotions without argumentation.