"Subclasses cannot override private methods. Subclass overrides of public methods can’t even see, let alone call, the superclass’s private methods. Problematic for, say, test mocks."
IMHO you don't want private methods to be visible in subclasses, because this makes the fragile base class problem worse. If I'm a framework developer working on a UI library, I should be free to add private methods to my Button class for the second version of my library without worrying that they'll influence the behavior of a FooButton that some app wrote that's derived from the class in the first version of my library.
The problem, of course, is testing. You want to be able to cleanly substitute mock objects for unit tests, without having to make everything depend on an interface or to use protected everywhere. It'd be nice if languages had more unit testing facilities built in. Microsoft Fakes is an interesting approach here.
The argument there is that your tests are telling you that your code has the wrong structure, so if you need to be getting at private methods in your tests, those private methods could be public methods on some delegatee you inject into the class under test.
I'm not convinced this is universally applicable, but I'm otherwise sympathetic to it.
Well, that's coming from the perspective of someone who doesn't like "private" in the first place; it forces me to rely on whatever use cases the author has imagined and makes extending the class in a novel manner a pain. Except this is PHP, so I can just go change the "private" to "public" anyway.
Namespacing within an inheritance tree is a problem, yes, but just hiding as much of your namespace as possible sucks. As does ahem ahem double-underscore prefixing. Surely there's another option here, but until someone figures out what it is, I'm okay risking collisions.
> it forces me to rely on whatever use cases the author has imagined and makes extending the class in a novel manner a pain
It's purpose is to isolate you from implementation details you're not supposed to care about and allow the library/framework developer to update their code without fear of breaking your components. It's also a form of enforced documentation.
"Subclasses cannot override private methods. Subclass overrides of public methods can’t even see, let alone call, the superclass’s private methods. Problematic for, say, test mocks."
IMHO you don't want private methods to be visible in subclasses, because this makes the fragile base class problem worse. If I'm a framework developer working on a UI library, I should be free to add private methods to my Button class for the second version of my library without worrying that they'll influence the behavior of a FooButton that some app wrote that's derived from the class in the first version of my library.
The problem, of course, is testing. You want to be able to cleanly substitute mock objects for unit tests, without having to make everything depend on an interface or to use protected everywhere. It'd be nice if languages had more unit testing facilities built in. Microsoft Fakes is an interesting approach here.