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

Question

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?

Answer 1

Yes.

A situation where a non-virtual protected method makes sense might be something like bool IsInitialized(). The class is designed to be sub-classed. The sub-class might provide new methods, or overriding methods. In either case, before these methods can be run, it is important to check that the class is initialized. So the IsInitialized() method is provided for that purpose. It is intended to be used by the new or overriding methods in the sub-class only, and not the calling code. It is also intended that IsInitialized() not be overridden. The way to provide this is by declaring IsInitialized() to be protected and non-virtual.

Answer 2

The point of protected is not that extension programmers are smarter than application programmers, and therefore are allowed more. They aren't. There's just fewer of them. There are valid arguments for why protected breaks encapsulation and should be avoided if possible; but the world is not perfect, and perfect encapsulation is not a good goal, because in practice it conflicts with too many other valid goals. Therefore it still makes sense to offer class authors a means to expose stuff to some but not all others. Being a good programmer largely consists in being able to make informed decisions about such trade-offs.

Answer 3

When you declare a class member protected, it does not mean that you do not want it used accidentally: that is what the private is for. You declare members protected when you have data or behavior that is useful to all subclasses, but not to the users of the class.

The simplest way to see this is examining the Template Method pattern: the base class exposes a service that is useful outside of the class, and provides protected methods that subclasses can override to supply partial behaviors to the template method.

Template method pattern uses protected virtual methods in combination with a public non-virtual one. The situation can be reversed, too - public virtual methods in derived classes may use a protected non-virtual method in the base class to supply data or behavior that should be protected from users outside of the base class. In nearly all situations when a protected member is involved there will be an associated virtual member somewhere along the inheritance chain.

Answer 4

Think like you are developing an API. Now you need to think how to make it much better so that users can use or can use with some customization.

In a API you need to use :

1. public methods : so that developers can use the provided features.
2. private methods : developers don't confused or your api breaks.
3. protected methods : so that if some are more intelligent and want to extend your code they can.

Sometimes while creating a software design/architecture we need to hide some internals from caller Classes but those are necessary by sub-classes. Example (Java): What if java.lang.Object changes protected void finalize() access to public or private. Definitely this would create problems.