Re: Is it poor design to have protected members in an abstract class?

From: Siemel Naran (SiemelNaran_at_REMOVE.att.net)
Date: 03/16/04


Date: Tue, 16 Mar 2004 17:59:53 GMT


"Julie" <julie@aol.com> wrote in message news:405732B7.7D459FF@aol.com...
> Claudio Puviani wrote:
> > "Julie" <julie@aol.com> wrote
> > > Siemel Naran wrote:

> > > > Fair, but I don't have problems with const protected data.
> > >
> > > Does someone have an objective reason why const _public_ data is
ill-advised?
> >
> > You can achieve the same thing by providing public methods that return
the same
> > data. In the future, the methods can be changed to act as forwarders, do
lazy
> > evaluation, maintain access statistics, etc. If the class just exposed
the data,
> > none of this would be possible without forcing the clients to change.
With an
> > inline accessor, the only additional cost is typing the parentheses.
Given this,
> > there's no good reason to expose the data directly.

Right. But if the const data variable is itself a class whose members do
lazy evaluation and all the other stuff, it's OK to make the member
protected for derived classes to see. I wouldn't make it public just
because that's a far bigger scope.

But you point out that the only disadvantage to inline functions is a few
extra characters, and for this reason I think it's better to prefer to make
even const data private, but I'm not willing to make it an absolute rule.
Thanks.

> class Shape
> {
> public:
> const unsigned int length;
> const unsigned int width;
> const unsigned int height;
> // etc.
> };

What if you want to change length to a unsigned long in the future? The
client code may depend on the type being unsigned int as when they form a
reference to a member variable, etc. Of course, you could solve this by

class Shape
{
public:
typedef unsigned int type;
const type length;
const type width;
const type height;
// etc.
};

and require users to employ the typedef.

> in my opinion is preferred over:
>
> class Shape
> {
> public:
> unsigned int Length();
> unsigned int Width();
> unsigned int Height();
> // etc.
> };

I like the second way, with the added typedef. I'd only consider protected
const data, and as long as the data type was not a fundamental or std::
type.



Relevant Pages