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: 236
object-oriented
|encapsulation
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