That's correct and exactly what the quote you are responding to said.
Changing the base class will most likely mean you need to changed the derived class anyway.
You did by assuming that a specific class is a leaf instead of just another branch.
Who said anything about final classes?
Private facilities aren't subject to refinement as are protected and public facilities in normal branch classes; final classes, in whatever from, aren't subject to further refinement of at all. These are very different considerations. A private facility says "I (as in this class) expect this facility to be implemented in exactly this fashion for my interface but you can refine the interface and implementation independently.". A final class says "It will never be useful to refine this class.".
I agree. That's why private seems pointless.
Why? If higher level facilities guarantee a contract why should you verify it?
You should really be checking if a pointer is null before you use it.
I'm being totally serious here, why verify the validity of a contract when that responsibility lies elsewhere?
Duplicating responsibilities is a good way to cause subtle bugs and trample performance.
Sure, checking a single pointer for null is cheap, but apply that same logic to large modern file systems. Imagine how slow your system would be if the file system driver had to check ever node in the system for validity before requesting a new node for file expansion. It would cripple your system. Instead, the driver has functions that do the job of guaranteeing (as much as is possible with unreliable hardware) the validity of "free store" every "free store" operation so the expansion code can safely assume the "free store" is ready to go.
That's a good rule of them for function parameters but not so much for class data members.
If it's never going to be null, then a reference should be used.
That aside, I can make a reference null. It is a violation of the C++ contract, but I can absolutely do it.
Are you going to start checking that a reference isn't null just because I can be a dick?
No. Of course you aren't. That would be foolish. You expect higher level facilities (in this case the C++ compiler) to do its job and the programmer to honor that contract.
The situation I'm explaining is exactly the same; you expect the `Base' class implementation to hold to that contract so checking it is meaningless.
True. However, private facilities aren't subject to this logic because the goal of "OOP" is programming to an interface not an implementation. Privates facilities are not part of the interface. They are part of the implementation. Consider the interface `doSomethingAwesome': if the `Base' implementation of `doSomethingAwesome' is implemented in terms of the private method `doSomething' derived classes can still `doSomethingAwesome' by doing the same thing the base class does (inherited implementation) or do something entirely different (override implementation). The private method used to implement `doSomethingAwesome' doesn't break anything.
If a base class can do X, the derived class should be able to as well.
That situation can't, by the very definition, violate the "IS-A" relationship. The "IS-A" relationship is about object substitution by interface leaving assumptions, contracts, preconditions, postconditions, and so on intact. The private aspects of an object aren't part of the interface. They are only part of the implementation.
If you make X private, the derived class won't be able to anymore.