'protected' vs. public members

[Jordan]

AFAIK there are two ways to expose members of a base class to a derived or
child class:
1. declare the members public in the base class
2. declare them as 'protected' in the base class

Is either of these methods generally recommended over the other? If yes,
why?

Thanks!

[rmacias]

Protected is like Private, except that Protected members can be accessed by
the base class, and child classes. Private members are not available to
child classes.

If you want your members to be accessed by child classes AND other classes,
use public. If you don't want other classes to access your member, but only
your child classes, use protected.

"Jordan" wrote:

AFAIK there are two ways to expose members of a base class to a derived or
child class:
1. declare the members public in the base class
2. declare them as 'protected' in the base class

Is either of these methods generally recommended over the other? If yes,
why?

Thanks!

[Michael Nemtsev]

Recomendation is design specific. 'Protected' declares that access is
limited to the containing class/types derived from its class.In other
words, it makes variable secured within original and derived classes.

--
Michael Nemtsev :: blog: http://spaces.msn.com/laflour
"At times one remains faithful to a cause only because its opponents do

not
cease to be insipid." (c) Friedrich Nietzsche

[Kevin Spencer]

General rule of thumb: Use the least amount of access you anticipate
needing, to make the best use of Encapsulation.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A brute awe as you,
a Metallic hag entity, eat us.
"rmacias" <rm*****@newsgroup.nospam> wrote in message
news:8A**********************************@microsof t.com...

Protected is like Private, except that Protected members can be accessed
by
the base class, and child classes. Private members are not available to
child classes.

If you want your members to be accessed by child classes AND other
classes,
use public. If you don't want other classes to access your member, but
only
your child classes, use protected.

"Jordan" wrote:

AFAIK there are two ways to expose members of a base class to a derived
or
child class:
1. declare the members public in the base class
2. declare them as 'protected' in the base class

Is either of these methods generally recommended over the other? If yes,
why?

Thanks!

[Jordan]

So then is it accurate to say that if a base class is virtual then there is
really no point in having public members (therefore make them protected)?


"rmacias" <rm*****@newsgroup.nospam> wrote in message
news:8A**********************************@microsof t.com...

Protected is like Private, except that Protected members can be accessed
by
the base class, and child classes. Private members are not available to
child classes.

If you want your members to be accessed by child classes AND other
classes,
use public. If you don't want other classes to access your member, but
only
your child classes, use protected.

"Jordan" wrote:

AFAIK there are two ways to expose members of a base class to a derived
or
child class:
1. declare the members public in the base class
2. declare them as 'protected' in the base class

Is either of these methods generally recommended over the other? If yes,
why?

Thanks!

[Jon Skeet [C# MVP]]

Jordan wrote:

So then is it accurate to say that if a base class is virtual then there is
really no point in having public members (therefore make them protected)?

Classes can't be virtual - do you mean abstract?

As for there being no point in having public members - no, if you want
to be able to get at a member from outside the inheritance hierarchy,
you *have* to make the member public (or internal).

Jon

[Mike]

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...

General rule of thumb: Use the least amount of access you anticipate
needing, to make the best use of Encapsulation.
That's the general OO wisdom - but that also means that either (a) the class
has to be extremely well designed or (b) you need to be clairvoyant to the
extent that you know beyond a shadow of a doubt what memebers may be needed
by people using your classes. (This is usually only a problem with extremely
complex classes.) If the consumer has the source, it's okay becuase they can
make changes.

I can't tell you how many times I can see the information I want in the
debugger as a private memember, but the library/framework writer has deemed
in their infinite wisdom that I don't need to see it. (final/sealed are also
very annoying.) It would be nice if languages had more control - maybe
levels like public(1), public(2) (or using attributes), for beginng vs.
advanced access (and maybe advanced access needs a digital signature from
the publisher), or something like member_access(obj, null/*perm*/,
_privMember) for when you know you're being a bad boy or girl but need to do
it anyway - this would also allow consumer-side source patches in sublcasses
until a new release could be delivered by the vendor. (I suppose reflection
is possible if the lib isn't obfuscated, etc.) Not that the CLR needs to
provide a fine-grained capibility architecture, but some additional access
control is probably useful.

Not that your rule isn't correct in general...

m

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
A brute awe as you,
a Metallic hag entity, eat us.
"rmacias" <rm*****@newsgroup.nospam> wrote in message
news:8A**********************************@microsof t.com...

Protected is like Private, except that Protected members can be accessed
by
the base class, and child classes. Private members are not available to
child classes.

If you want your members to be accessed by child classes AND other
classes,
use public. If you don't want other classes to access your member, but
only
your child classes, use protected.

"Jordan" wrote:

AFAIK there are two ways to expose members of a base class to a derived
or
child class:
1. declare the members public in the base class
2. declare them as 'protected' in the base class

Is either of these methods generally recommended over the other? If yes,
why?

Thanks!

[Kevin Spencer]

Hi Mike,

I too have been frustrated with this sort of encapsulation. But I can
understand it. If you market a class, and provide people with the ability to
abuse it, you can have a support nightmare on your hands. In addition, it
can work in your favor as a software development business.

As for being extremely well-designed, that is of course another rule of
thumb! ;-)

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A brute awe as you,
a Metallic hag entity, eat us.
"Mike" <vi********@yahoo.com> wrote in message
news:eY**************@TK2MSFTNGP14.phx.gbl...

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...

General rule of thumb: Use the least amount of access you anticipate
needing, to make the best use of Encapsulation.

That's the general OO wisdom - but that also means that either (a) the
class has to be extremely well designed or (b) you need to be clairvoyant
to the extent that you know beyond a shadow of a doubt what memebers may
be needed by people using your classes. (This is usually only a problem
with extremely complex classes.) If the consumer has the source, it's okay
becuase they can make changes.

I can't tell you how many times I can see the information I want in the
debugger as a private memember, but the library/framework writer has
deemed in their infinite wisdom that I don't need to see it. (final/sealed
are also very annoying.) It would be nice if languages had more control -
maybe levels like public(1), public(2) (or using attributes), for beginng
vs. advanced access (and maybe advanced access needs a digital signature
from the publisher), or something like member_access(obj, null/*perm*/,
_privMember) for when you know you're being a bad boy or girl but need to
do it anyway - this would also allow consumer-side source patches in
sublcasses until a new release could be delivered by the vendor. (I
suppose reflection is possible if the lib isn't obfuscated, etc.) Not
that the CLR needs to provide a fine-grained capibility architecture, but
some additional access control is probably useful.

Not that your rule isn't correct in general...

m

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
A brute awe as you,
a Metallic hag entity, eat us.
"rmacias" <rm*****@newsgroup.nospam> wrote in message
news:8A**********************************@microsof t.com...

Protected is like Private, except that Protected members can be accessed
by
the base class, and child classes. Private members are not available to
child classes.

If you want your members to be accessed by child classes AND other
classes,
use public. If you don't want other classes to access your member, but
only
your child classes, use protected.

"Jordan" wrote:

AFAIK there are two ways to expose members of a base class to a derived
or
child class:
1. declare the members public in the base class
2. declare them as 'protected' in the base class

Is either of these methods generally recommended over the other? If
yes,
why?

Thanks!

[Bruce Wood]

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.