'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]

RE: 'protected' vs. public members

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:
[color=blue]
> 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!
>
>
>[/color]

[Michael Nemtsev]

Re: 'protected' vs. public members

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]

Re: 'protected' vs. public members

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" <rmacias@newsgr oup.nospam> wrote in message
news:8A601A51-2113-4752-A137-4B6C94D5195C@mi crosoft.com...[color=blue]
> 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:
>[color=green]
>> 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!
>>
>>
>>[/color][/color]

[Jordan]

Re: 'protected' vs. public members

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" <rmacias@newsgr oup.nospam> wrote in message
news:8A601A51-2113-4752-A137-4B6C94D5195C@mi crosoft.com...[color=blue]
> 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:
>[color=green]
>> 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!
>>
>>
>>[/color][/color]

[Jon Skeet [C# MVP]]

Re: 'protected' vs. public members

Jordan wrote:[color=blue]
> 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)?[/color]

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]

Re: 'protected' vs. public members


"Kevin Spencer" <kevin@DIESPAMM ERSDIEtakempis. com> wrote in message
news:%237pJuRfP GHA.516@TK2MSFT NGP15.phx.gbl.. .[color=blue]
> General rule of thumb: Use the least amount of access you anticipate
> needing, to make the best use of Encapsulation.[/color]

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(o bj, 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
[color=blue]
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> A brute awe as you,
> a Metallic hag entity, eat us.
>
>
> "rmacias" <rmacias@newsgr oup.nospam> wrote in message
> news:8A601A51-2113-4752-A137-4B6C94D5195C@mi crosoft.com...[color=green]
>> 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:
>>[color=darkred]
>>> 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!
>>>
>>>
>>>[/color][/color]
>
>[/color]

[Kevin Spencer]

Re: 'protected' vs. public members

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" <vimakefile@yah oo.com> wrote in message
news:eYNJatiPGH A.2696@TK2MSFTN GP14.phx.gbl...[color=blue]
>
> "Kevin Spencer" <kevin@DIESPAMM ERSDIEtakempis. com> wrote in message
> news:%237pJuRfP GHA.516@TK2MSFT NGP15.phx.gbl.. .[color=green]
>> General rule of thumb: Use the least amount of access you anticipate
>> needing, to make the best use of Encapsulation.[/color]
>
> 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(o bj, 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
>[color=green]
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> .Net Developer
>> A brute awe as you,
>> a Metallic hag entity, eat us.
>>
>>
>> "rmacias" <rmacias@newsgr oup.nospam> wrote in message
>> news:8A601A51-2113-4752-A137-4B6C94D5195C@mi crosoft.com...[color=darkred]
>>> 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!
>>>>
>>>>
>>>>[/color]
>>
>>[/color]
>
>[/color]

[Bruce Wood]

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.