protected members

[Nick Keighley]

Hi,

I'm curious about best practice for protected members.

Consider this code fragment:-
class Patch
{
public:
Patch ();
virtual void draw (Page, int x, int y) = 0;
protected:
unsigned size () const { return size_; }
void set_size (unsigned size) { size_ = size; }
private:
unsigned size_;
};

class Plain_patch: public Patch
{
public:
Plain_Patch ();
virtual void draw (Page, int x, int y);
};

Plain_Patch::draw (Page page, int x, int y)
{
// uses size() function
}


In order for the derived class to implement its draw() method it needs
to know the size. Protected data seems to be frowned on. So is my only
choice protected get() and set() methods? Or public?

 

[Alf P. Steinbach]

* Nick Keighley:

In order for the derived class to implement its draw() method it needs
to know the size.

Make the size value available to the derived class, e.g. a member function
size().

Protected data seems to be frowned on.

No.

It has its uses.

E.g., std::queue::c is a protected data member.

So is my only choice protected get() and set() methods?

Don't provide a setter member function unless it's required.

I'd call the getter "size".

In C++ there's advantage to using a "get" prefix.

Or public?

Why shouldn't size() be public? It's naturally public. It seems you
haven't included the constraints on your design, yet ask how to solve
something within those constraints -- we're not telepaths.

 

[Nick Keighley]

* Nick Keighley:

Make the size value available to the derived class, e.g. a member function
size().


No.

It has its uses.

E.g., std::queue::c is a protected data member.



Don't provide a setter member function unless it's required.

there are other methods that use the set. Hmm... re-examining the code
the set method shouldn't be necessary. The objects are given a size
when they are created and shouldn't change.

I'd call the getter "size".

In C++ there's advantage to using a "get" prefix.

"[no] advantage"?

Why shouldn't size() be public? It's naturally public. It seems you
haven't included the constraints on your design, yet ask how to solve
something within those constraints -- we're not telepaths.

it seemed to be exporting infomation unnecessarily. The only users of
the size of the object are the draw() methods. Perhaps I'm
unnecessarily constraining the design.

 

[Cy Edmunds]

Well, std:air has public data members, but that doesn't mean public data
members are a great idea. I think protected data members are a generally bad
idea in agreement with the phrase "frowned on".

Don't provide a setter member function unless it's required.

there are other methods that use the set. Hmm... re-examining the code
the set method shouldn't be necessary. The objects are given a size
when they are created and shouldn't change.

I'd call the getter "size".

In C++ there's advantage to using a "get" prefix.

"[no] advantage"?

Why shouldn't size() be public? It's naturally public. It seems you
haven't included the constraints on your design, yet ask how to solve
something within those constraints -- we're not telepaths.

it seemed to be exporting infomation unnecessarily. The only users of
the size of the object are the draw() methods. Perhaps I'm
unnecessarily constraining the design.

Your size() function should be either protected or private depending on
factors we can't judge from what you've told us. I agree that the end user's
interface should be as simple as possible. On the other hand if your usage
scenario isn't completely clear it might be advisable to make size() public.
It wouldn't be a serious mistake to do so in any case.

 

[Alf P. Steinbach]

* Cy Edmunds:

Well, std:air has public data members, but that doesn't mean public data
members are a great idea. I think protected data members are a generally bad
idea in agreement with the phrase "frowned on".

If you're going to argue, at least make some kind of connection, even the
vaguest, touchy-feely kind, from premise to conclusion.

Having a pet "that's bad" or "that's good" idea is unfortunately very
common.

 

[leonardo77]

Alf P. Steinbach:

If you're going to argue, at least make some kind of connection, > even the vaguest, touchy-feely kind, from premise to conclusion.

Having a pet "that's bad" or "that's good" idea is unfortunately very
common.

To my perception Cy Edmunds might be correct at this point.
Protected data is frowned upon for the same reason as public data.
(It's even worse,there are in fact some possible uses of public data,
aka. bag of bits or std:air).
Derived classes are as coupled to the protected data/interface of their
base classes as the rest of the world to the public data/interface.
as the rest of the world.
Still,if the application is reasonably small or you can control the
changes,you can just stick to protected data to avoid complications.

 

[Bob Hairgrove]

On 17 Jul 2005 07:09:41 -0700, "Nick Keighley"

[snip]

In order for the derived class to implement its draw() method it needs
to know the size. Protected data seems to be frowned on. So is my only
choice protected get() and set() methods? Or public?

I would implement some virtual "getSize()" function. You never know if
this needs to be extended in the future. Perhaps you will want to take
into consideration some scaling factor for certain derived classes?

Bjarne Stroustrup, in "The C++ Programming Language" (p. 405 of the
3rd edition) states that "declaring data members protected is usually
a design error". Later, he goes on to say that this creates a
"software maintenance problem".

To me, it never became obvious what he meant until I started working
on one of my first fairly large projects. It became painfully obvious
when the member (a pointer) was in the base class, and the derived
class was supposed to initialize it as well as call delete on this
pointer in the derived destructor. Wasn't well documented, either. Now
consider having to check 30 or 40 different projects to make sure that
this was done correctly, and you'll see what I mean.

For invariants implemeneted as const members, though, I think there is
no danger of declaring them protected. In practice, though, I think
one finds very few instances of this compared to very many instances
of the abuse of protected members.

 

[Alf P. Steinbach]

* Bob Hairgrove:

On 17 Jul 2005 07:09:41 -0700, "Nick Keighley"

[snip]

In order for the derived class to implement its draw() method it needs
to know the size. Protected data seems to be frowned on. So is my only
choice protected get() and set() methods? Or public?

I would implement some virtual "getSize()" function. You never know if
this needs to be extended in the future. Perhaps you will want to take
into consideration some scaling factor for certain derived classes?

Bjarne Stroustrup, in "The C++ Programming Language" (p. 405 of the
3rd edition) states that "declaring data members protected is usually
a design error". Later, he goes on to say that this creates a
"software maintenance problem".

To me, it never became obvious what he meant until I started working
on one of my first fairly large projects. It became painfully obvious
when the member (a pointer) was in the base class, and the derived
class was supposed to initialize it as well as call delete on this
pointer in the derived destructor.

Deferring initialization responsibility to derived classes is generally bad,
yes.

It can be done with or without 'protected', and so is an orthogonal issue.

Any understanding you thought you gained about 'protected' from that is
therefore probably something you should forget at earliest opportunity.

Wasn't well documented, either.

That's generally bad, yes.

It can be done with or without 'protected', and so is an orthogonal issue.

Any understanding you thought you gained about 'protected' from that is
therefore probably something you should forget at earliest opportunity.