is 'protected' ever reasonable outside of virtual methods and destructors?
- by notallama
so, suppose you have some fields and methods marked protected (non-virtual). presumably, you did this because you didn't mark them public because you don't want some nincompoop to accidentally call them in the wrong order or pass in invalid parameters, or you don't want people to rely on behaviour that you're going to change later.
so, why is it okay for that nincompoop to use those fields and methods from a subclass? as far as i can tell, they can still screw up in the same ways, and the same compatibility issues still exist if you change the implementation.
the cases for protected i can think of are:
non-virtual destructors, so you can't break things by deleting the base class.
virtual methods, so you can override 'private' methods called by the base class.
constructors in c++. in java/c# marking the class as abstract will do basically the same.
any other use cases?
