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 certa

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.