protected data - C++ Language (Moderated)

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

protected data

C++Talk.NET Forum Index -> C++ Language (Moderated)

View previous topic :: View next topic

Author

Message

Emily Winch
Guest

Posted: Fri Sep 26, 2003 10:38 am Post subject: protected data

I have been having a discussion with a colleague about under what circumstances it is reasonable to use protected data. He raised section 19.8 of the C++ FAQ in his defence, in which it states that on a small team, where derived classes will not be created by anyone outside the team, it is a waste of time putting in the effort to avoid protected data. I disagree with this entirely! I figure that either there is an implied interface for derived classes, in which case it saves time to implement it in code rather than explain it to the team (and risk them misunderstanding or forgetting), or alternatively, there really is no interface - i.e. nobody has thought about it - in which case it's necessary to spend enough time to establish what it is, in order to avoid bugs and rework. So, I am now curious to know whether I have in fact "spent my entire life in an ivory tower" as the FAQ suggests, or whether other people with real-world experience agree with me? Emily [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]

Anthony Williams
Guest

Posted: Sat Sep 27, 2003 1:33 am Post subject: Re: protected data

Emily Winch <usenet (AT) blueumbrella (DOT) net> writes:

Quote:

I have been having a discussion with a colleague about under what
circumstances it is reasonable to use protected data. He raised section
19.8 of the C++ FAQ in his defence, in which it states that on a small
team, where derived classes will not be created by anyone outside the
team, it is a waste of time putting in the effort to avoid protected data.

I disagree with this entirely! I figure that either there is an implied
interface for derived classes, in which case it saves time to implement
it in code rather than explain it to the team (and risk them
misunderstanding or forgetting), or alternatively, there really is no
interface - i.e. nobody has thought about it - in which case it's
necessary to spend enough time to establish what it is, in order to
avoid bugs and rework.

I agree with you in general --- protected data should be avoided. However, I
have recently found cause to use it when refactoring legacy code --- as a
first step towards tidying up a class hierarchy with *public* data, I
converted all the data to protected, with an appropriate interface to the
outside world. Identifying the actual internal interface for the derived
classes and defining the appropriate set of protected member functions is the
next step.

Anthony
--
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely response.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Francis Glassborow
Guest

Posted: Sat Sep 27, 2003 1:42 am Post subject: Re: protected data

In article <bkvn49$igb$2 (AT) titan (DOT) btinternet.com>, Emily Winch
<usenet (AT) blueumbrella (DOT) net> writes

Quote:

I think the fault with this is 'where derived classes will not be
created by anyone outside the team.' which is, in practice, never
knowable unless the source code is never ever published under any
circumstances. Like all secrets, once it has been shared with at least
one other person it is no longer a secret.

There is also the issue that even in a small team (of one) that it locks
your implementation of the data structure.

BTW if the team is so trustworthy, then just make all data public and be
done with it. :-)

--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

WW
Guest

Posted: Sat Sep 27, 2003 10:30 am Post subject: Re: protected data

Emily Winch wrote:

Quote:

A small team? When? Now? How about a week from now? How about a year
from now? How about 10 years from now?

Quote:

I disagree with this entirely! I figure that either there is an
implied interface for derived classes, in which case it saves time to
implement it in code rather than explain it to the team (and risk them
misunderstanding or forgetting), or alternatively, there really is no
interface - i.e. nobody has thought about it - in which case it's
necessary to spend enough time to establish what it is, in order to
avoid bugs and rework.

Exactly. Furthermore what happens to a small teams small code? Let's
suppose it is written, the team is *good*, it is bug free. It is bug free
enough that no one needs to touch it for 6 years. When a change request
arrives. The small team was full of very exceptional people. They have
been so creative that they have got bored with programming. One of them is
in deep Africa bird watching, the other is hibernated as he is moving on a
space ship towards Jupiter, the third one is a rock star and there is no way
to contact him... What I am trying to get at with this silly thing is that
the code (if possible) should be its own documentation.

It is dangerous to leave quality to airborn infection (verbal
communication). I frequently find it true, that in a large enough
organization of the documentation is a separate piece of thing, it will sink
into a document retrieval system and no one will ever know it is there or
ever read it or update it. So as the instructions are always written on the
front of a vending machine (even though the ones giving soda are nowadays
the same all around the world) so should we make our code self-contained.

In many of the cases you need to touch an old or abandoned code it is a sort
of emergency. (As everything nowadays in programming. Sad

) Su you really
want to have every possible information in there - the code has ot suggest
its proper usage.

I think that it might be rare one needs to define a separate interface for
the hierarchy. This also supports the idea that since it is an unusal case,
it *must* be documented in the code, preferably on a way that if it is
violated the code does not compile.

It is also important to note that an /interface/ is usually (better be) a
set of functions. IMHO the waste of time is not to make functions (and I am
in opposition with the FAQ). Furthermore I think that the main issue is:
why do you have that internal interface in the first place? And the second
one is: how come that internal interface is not an interface, but it
completely opens up a way to access the privates (khm, no pun intended) of
the base class, without leaving *any* control of it?

Why do I say these? Because sowftare tends to change. The change sooner or
later will lead to one of two situations: the base class will need a change;
one of the derived classes will start to cr*w up the base's state. And in
any of these cases the time lost will be much more than the time spent on
making the right interface.

Furthermore if we talk about interface that is not setAMember(int), int
getAMember()! And interface *must* talk in the terms of the "outside", that
little "problem" domain represented by the derived classes. And I have to
say that I have rarely seen any but one technical reason to use the
protected keyword: the base class defines a managed resource and friendship
for the manager. But it cannot define it destructor private, because then
no inheritance is possible. IMHO *all* other cases can be solved by the
Template Method Pattern. I - of course - might be wrong.

Putting protected interface into a class hierarchy creates a very strong
coupling between the base and the derived classes. Any change to the base
will force a change on all derived classes. The reasons of existence of
such an interface (not only protected data, *any* inteface) has to be very
well justified, because it creates a debt for the future.

Quote:

So, I am now curious to know whether I have in fact "spent my entire
life in an ivory tower" as the FAQ suggests, or whether other people
with real-world experience agree with me?

Ah. I have got a vision. You, leaning out of the window of your ivory
tower, letting your hair fall down, so that Andrei - waiting down there in
his cloak - can climb up and hide his leather-cover book of deep template
metaprogramming wizardy from the mugglies of languages without templates.
:-)

--
WW aka Attila

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Dietmar Kuehl
Guest

Posted: Sat Sep 27, 2003 10:31 am Post subject: Re: protected data

Emily Winch wrote:

Quote:

There is no such thing as "a small team"! Team members change, if the
classes are any good it will be desirable to use them in other projects,
successful projects grow, etc. Not encapsulating data will lead to
severe problems down the road: even in a small team, people forget
that data members are used by a derived class (at least, if I'm on the
team: I will surely forget). ... and the tighter the schedule, the less
like people will be to check whether they actually can change a data
member.

Exposing data members to the outside of a class is, even in a small
team, a sure path towards desaster. Actually, not cleanly used data
members with *one* class are already a problem: have you never
encountered a situation where you changed a [private] data member in
a method just to find that this causes a problem because the assumptions
made about this data member are tighter than you thought? At least to me
this happens occasionally - even when working on my own code: I can't
remember all details after not looking at the code for year or so (well,
actually a month is often sufficient...). That is, data encapsulation on
class level is already sometimes too course. Exposing data to derived
classes makes things much worse!

In short: public or protected data is a problem. You should not have it
- at least not in any class with more complex than trivial logic. PODs
without any logic, like eg. 'std::pair<>' are fine with public data.
Any bit of assumptions about non-private data will be violated. But I
would take even a step futher: there is no point in protected functions!
(for an exception see below) Either the client of a function does not
have to make any assumptions, in which case a function can be freely
called from both derived class as well as from any other functions, or
assumptions on the object's integrity have to be made in which case the
object is not well encapsulated. Why does everybody assume that derived
classes are any better behaved than other clients?

Actually, I have so far only found one good reason to have protected
methods in the first place: virtual functions for which it makes sense
to call the base class implementation from the overriding function (of
course, some people are opposed to deriving from classes which have any
implementation at all - there is no reason for protected functions in
this case...). The typical objection to this view is caused by
misinformation: people don't realize that you can override private
functions - you just can't call them from a derived class.

If everybody would remember everything, would be informed in depth,
and would be well-behaved there would be no need for any form of
encapsulation. But we are not living in such a world. Everything bigger
than a project of very few people and very days will benefit from
encapsulation - and the fact that you seem to use C++ indicates that
you are not doing such a small project.
--
<mailto:dietmar_kuehl (AT) yahoo (DOT) com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Siemel Naran
Guest

Posted: Sat Sep 27, 2003 2:13 pm Post subject: Re: protected data

"Emily Winch" <usenet (AT) blueumbrella (DOT) net> wrote

Quote:

But simple projects and small teams can turn into big ones.

Quote:

I disagree with this entirely! I figure that either there is an implied
interface for derived classes, in which case it saves time to implement
it in code rather than explain it to the team (and risk them
misunderstanding or forgetting), or alternatively, there really is no
interface - i.e. nobody has thought about it - in which case it's
necessary to spend enough time to establish what it is, in order to
avoid bugs and rework.

Good point. Besides, it's easy to provide accessor or action functions.
But I have no problems with protected data that is const.

--
+++++++++++
Siemel Naran

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

James Kanze
Guest

Posted: Sat Sep 27, 2003 5:09 pm Post subject: Re: protected data

Emily Winch <usenet (AT) blueumbrella (DOT) net> writes:

Quote:

I have been having a discussion with a colleague about under what
circumstances it is reasonable to use protected data. He raised
section 19.8 of the C++ FAQ in his defence, in which it states that
on a small team, where derived classes will not be created by anyone
outside the team, it is a waste of time putting in the effort to
avoid protected data.

I disagree with this entirely! I figure that either there is an
implied interface for derived classes, in which case it saves time
to implement it in code rather than explain it to the team (and risk
them misunderstanding or forgetting), or alternatively, there really
is no interface - i.e. nobody has thought about it - in which case
it's necessary to spend enough time to establish what it is, in
order to avoid bugs and rework.

So, I am now curious to know whether I have in fact "spent my entire
life in an ivory tower" as the FAQ suggests, or whether other people
with real-world experience agree with me?

My real world experience suggests that, according to the above, one
person is a large team. In my experience, things that aren't written
down in some form (and given the context, expressing them directly in
C++ seems the best way of writing them down) aren't fully understood, or
fixed. Even when I'm writing code for myself, I start by putting the
contract in writing -- and when the contract can be expressed in C++,
and verified by the compiler, that's the route I take.

--
James Kanze mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Ron Natalie
Guest

Posted: Sun Sep 28, 2003 1:27 am Post subject: Re: protected data

"Siemel Naran" <SiemelNaran (AT) REMOVE (DOT) att.net> wrote

Quote:

Good point. Besides, it's easy to provide accessor or action functions.
But I have no problems with protected data that is const.

Then how do you feel about public data that is const?

-Ron

The coin of the C++ realm is legal tender for all debts public, protected, and private.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Emily Winch
Guest

Posted: Sun Sep 28, 2003 2:05 am Post subject: Re: protected data

Dietmar Kuehl wrote:

Quote:

Emily Winch wrote:

I have been having a discussion with a colleague about under what
circumstances it is reasonable to use protected data. He raised section
19.8 of the C++ FAQ in his defence, in which it states that on a small
team, where derived classes will not be created by anyone outside the
team, it is a waste of time putting in the effort to avoid protected data.

There is no such thing as "a small team"! Team members change, if the
classes are any good it will be desirable to use them in other projects,
successful projects grow, etc. Not encapsulating data will lead to
severe problems down the road: even in a small team, people forget
that data members are used by a derived class (at least, if I'm on the
team: I will surely forget). ... and the tighter the schedule, the less
like people will be to check whether they actually can change a data
member.

This is exactly my argument.

Quote:

Actually, I have so far only found one good reason to have protected
methods in the first place: virtual functions for which it makes sense
to call the base class implementation from the overriding function (of
course, some people are opposed to deriving from classes which have any
implementation at all - there is no reason for protected functions in
this case...). The typical objection to this view is caused by
misinformation: people don't realize that you can override private
functions - you just can't call them from a derived class.

This is the argument I started with - that there was very very rarely
any reason to have protected functions _or_ data.

Quote:

If everybody would remember everything, would be informed in depth,
and would be well-behaved there would be no need for any form of
encapsulation. But we are not living in such a world. Everything bigger
than a project of very few people and very days will benefit from
encapsulation - and the fact that you seem to use C++ indicates that
you are not doing such a small project.

It's interesting that now you appear to agree with my colleague and with
the FAQ - that _if_ the project is small, there is justification for not
bothering to write a protected interface. This is what I disagree with
(although I am happy to be convinced otherwise).

Emily.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Siemel Naran
Guest

Posted: Sun Sep 28, 2003 10:23 pm Post subject: Re: protected data

"Ron Natalie" <ron (AT) sensor (DOT) com> wrote

Quote:

"Siemel Naran" <SiemelNaran (AT) REMOVE (DOT) att.net> wrote

Quote:

Good point. Besides, it's easy to provide accessor or action functions.
But I have no problems with protected data that is const.

Then how do you feel about public data that is const?

Avoid it because it violates the principles of encapsulation, explained
eloquently in other posts on this thread. Protected data is not as bad
because writers of derived classes are supposed to know the interface. So I
have no problem with a protected member protected: const Thing d_thing.
There's no benefit to provide an accessor function that returns a const
Thing& it's really the same as d_thing. Now non-const data is bad because
the derived class can change the value, and the base class function wouldn't
know about it, and things could go wrong or the program would be hard to
understand.

--
+++++++++++
Siemel Naran

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Dietmar Kuehl
Guest

Posted: Mon Sep 29, 2003 10:00 pm Post subject: Re: protected data

Emily Winch wrote:

Quote:

Dietmar Kuehl wrote:
If everybody would remember everything, would be informed in depth,
and would be well-behaved there would be no need for any form of
encapsulation. But we are not living in such a world. Everything bigger
than a project of very few people and very days will benefit from
encapsulation - and the fact that you seem to use C++ indicates that
you are not doing such a small project.

It's interesting that now you appear to agree with my colleague and with
the FAQ - that _if_ the project is small, there is justification for not
bothering to write a protected interface.

Well, maybe I should have been more explicit in the first place: There
is no justification for not bothering about the protected interface -
when using C++. There is no such thing as encapsulation eg. in sh, there
is very little if any encapsulation in Perl, TCL, VisualBasic, etc.
Small projects often benefit from using these tool rather than using C++
to accomplish the task. Sometimes, C++ is the right choice for such
small projects but there are normally no encapsulation issues in the
first place because the code is merely a collection of statements without
any classes. Classes, in any OO language, make only sense when having a
reasonable interface, cleanly encapsulating their business - independent
of the project size.
--
<mailto:dietmar_kuehl (AT) yahoo (DOT) com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Shay
Guest

Posted: Mon Sep 29, 2003 10:11 pm Post subject: Re: protected data

Siemel Naran wrote:

Quote:

Ron Natalie wrote:
Siemel Naran wrote:
Good point. Besides, it's easy to provide accessor or action functions.
But I have no problems with protected data that is const.

Then how do you feel about public data that is const?

Avoid it because it violates the principles of encapsulation, explained
eloquently in other posts on this thread. Protected data is not as bad
because writers of derived classes are supposed to know the interface. So I
have no problem with a protected member protected: const Thing d_thing.
There's no benefit to provide an accessor function that returns a const
Thing& it's really the same as d_thing. Now non-const data is bad because
the derived class can change the value, and the base class function wouldn't
know about it, and things could go wrong or the program would be hard to
understand.

Classes have two interfaces to the outside world: public and protected.
Why do the above reasons only apply to protected interfaces? How are
protected clients any less-deserving of insulation than public clients?

(Bluntly, I think that the monster of exposing implementation has found a
back door into your thinking.)

--
Shay

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Display posts from previous:

	C++Talk.NET Forum Index -> C++ Language (Moderated)	All times are GMT
Page 1 of 1

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum