is 'protected' ever reasonable outside of virtual methods and destructors?

Posted by notallama on Programmers See other posts from Programmers or by notallama
Published on 2012-08-29T14:05:20Z Indexed on 2012/08/29 15:49 UTC
Read the original article Hit count: 242

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?

© Programmers or respective owner

Related posts about object-oriented

Related posts about encapsulation