Re: 'protected' vs. public members

I think that you mean "abstract," not "virtual."

Whether something should be public or protected has to do with what you
want your class to "look like" on the outside. There is no broad rule
of thumb you can blindly apply to get things right the first time. All
you can do is think about the many considerations and then decide on an
overall design for your class hierarchy. Some things to consider.

1. For simple class design, you must remember that there are two
potential "outside users" of your class: other, unrelated classes and
child classes (that inherit from your class). When designing the
functionality of your class, keep it clear what functions are part of
the class's public functionality, and what functions are appropriate
only for inheriting classes. Here I use the word "function" to indicate
method or property.

For examples, look at the Framework classes. Many of them have On...
methods that invoked whenever an event happens. It's not appropriate
that "complete strangers" be able to call these methods and have the
class act as though it's raising an event. They're there to make coding
child classes easier, so they're "protected".

2. Remember that you have to support whatever you export, and if you
export protected methods and properties than you have to support two
outside users: the public (unrelated) user and the protected (child
class) developer. However, if you have an abstract class then of course
you need to support inheritors... that's what the class is for.

3. For more sophisticated design there are also "internal" and
"protected internal" access modifiers that allow you to limit the use
of methods and properties to classes inside your own assembly.

Anyway, the point is that when you design a class from the outset, you
have to sit down and decide what "public" functionality it's going to
provide. If it's an abstract class, or you intend that others inherit
from it (abstract or not) then you have to do that exercise twice: once
for "public" functionality and once for "protected" functionality for
eventual inheritors.

The decision as to what protection each class member receives has to do
with the intended purpose of the member, and no arbitrary rule can tell
you that.

.