data members as "protected" ?

[Act]

Why is it suggested to not define data members as "protected" ?

Thanks for help!

[JKop]

Act posted:

Why is it suggested to not define data members as "protected" ?

Thanks for help!

Why is it suggested to not walk around alone at night?

Thanks for help!
-JKop

[Mike Wahler]

"Act" <ot***@hash.com > wrote in message
news:Q6******** *************@b gtnsc04-news.ops.worldn et.att.net...

Why is it suggested to not define data members as "protected" ?

IMO that's too general an advice to be meaningful. From
where did you get this suggestion?

Specifying a member (data or function) as 'protected'
means that derived classes have direct access to them.
Use 'protected' if that's what you need.

-Mike

[Daniel T.]

"Act" <ot***@hash.com > wrote:

Why is it suggested to not define data members as "protected" ?

The assumption is that the member data was put in this particular class
because there was some invariant that has to be maintained and this
class is the one designated to maintain it.

Obviously, given the case above, the class can't ensure the invariant if
it can't control access to the data.

What if the assumption doesn't hold? In that case, you might as well
make the data public.

[White Wolf]

Act wrote:

Why is it suggested to not define data members as "protected" ?

Because derived classes depending on it will be too dependent on their
bases. Why is that a problem? Because if youy want/need to change your
base class design you cannot. Because derived class (you may not even know
about) depend on those protected members to be there and not to change. And
experience shows that data members do change.

--
WW aka Attila
:::
Don't believe everything you think.

[David Hilsee]

"Act" <ot***@hash.com > wrote in message
news:Q6******** *************@b gtnsc04-news.ops.worldn et.att.net...

Why is it suggested to not define data members as "protected" ?

Some suggest that, some don't. I generally avoid protected data members,
but some people don't mind. For instance, the answers in the FAQ
(http://www.parashift.com/c++-faq-lite/) under "Inheritanc e — basics",
questions 8 and 9 lean towards protected data. I must admit that the
paragraph deriding "purists" is a bit, er, melodramatic.

--
David Hilsee

[John Brown]

> > Why is it suggested to not define data members as "protected" ?

IMO that's too general an advice to be meaningful. From
where did you get this suggestion?

Stroustrup for one (referring to protected data in particular). See section
15.3.1.1 in http://www.research.att.com/~bs/3rd.html

[Cy Edmunds]

"David Hilsee" <da************ *@yahoo.com> wrote in message
news:1f******** ************@co mcast.com...

"Act" <ot***@hash.com > wrote in message
news:Q6******** *************@b gtnsc04-news.ops.worldn et.att.net...

Why is it suggested to not define data members as "protected" ?
Some suggest that, some don't. I generally avoid protected data members,
but some people don't mind. For instance, the answers in the FAQ
(http://www.parashift.com/c++-faq-lite/) under "Inheritanc e - basics",
questions 8 and 9 lean towards protected data.

"Lean"? hehe
I must admit that the
paragraph deriding "purists" is a bit, er, melodramatic.

--
David Hilsee

My take on this is that whenever you use the keyword "protected" you are
expecting your client to derive from the class. In such a case I don't see
why protected data is any better than public data -- either way you are
giving your client full access to your implementation details. The FAQ makes
a big distinction between cases where you expect the client to be "on your
team" or not. Even if I could be sure my client is on my team I don't see
how that makes bad software design practices suddenly desirable. Would you
use public data if you thought your client was on your team? I hope not.

The FAQ also mentions the dubious practice of replacing protected data with
protected get/set methods. I agree, but I don't think public get/set methods
are so hot either.

--
Cy
http://home.rochester.rr.com/cyhome/

[Alf P. Steinbach]

* Cy Edmunds:

"David Hilsee" <da************ *@yahoo.com> wrote in message
news:1f******** ************@co mcast.com...

"Act" <ot***@hash.com > wrote in message
news:Q6******** *************@b gtnsc04-news.ops.worldn et.att.net...

Why is it suggested to not define data members as "protected" ?
Some suggest that, some don't. I generally avoid protected data members,
but some people don't mind. For instance, the answers in the FAQ
(http://www.parashift.com/c++-faq-lite/) under "Inheritanc e - basics",
questions 8 and 9 lean towards protected data.

"Lean"? hehe

I must admit that the
paragraph deriding "purists" is a bit, er, melodramatic.

--
David Hilsee

My take on this is that whenever you use the keyword "protected" you are
expecting your client to derive from the class. In such a case I don't see
why protected data is any better than public data -- either way you are
giving your client full access to your implementation details.

A derived class (on the one hand) and so-called client code (on the other
hand) are two different kinds of client.

A derived class is a fully trusted client: you're giving it access to your
innards, and if it screws up then you (or it) is dead anyway.

So-called client code is a non-trusted client: you're doing your utmost to
ensure that nothing client code can do while _adhering_ to the stated
contracts can screw up anything. But on the gripping hand it's futile to
try to protect against intentional misdeeds. Anyone can reinterpret_cas t,
and/or make their own modified class declaration, or whatever, so the
protection levels should be assigned with that in mind: you're not protecting
agains intentional hacking and misdeeds, but against accidental blunders, and
the care you can and must assume in the client depends on the kind of client.
The FAQ makes
a big distinction between cases where you expect the client to be "on your
team" or not.

A good point, but "on your team", if that's the expression the FAQ uses, is
a bit misleading.

It should be more like "part of your body"... ;-)

But these times even that is perhaps not strong enough: a derived class is
a very, Very, VERY intimate & strong relationship.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Alf P. Steinbach]

* John Brown:

Why is it suggested to not define data members as "protected" ?

IMO that's too general an advice to be meaningful. From
where did you get this suggestion?

Stroustrup for one (referring to protected data in particular). See section
15.3.1.1 in http://www.research.att.com/~bs/3rd.html

Perhaps you would kindly quote the passage instead of giving a reference
that doesn't contain or give further reference to the passage.

I once had the 3rd edition but now am left with only 1st and 2nd editions.

Anyway it's not our job to do the work in making your argument: DIY.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?