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
- Next message: Claudio Puviani: "Re: Merging mixed data sets"
- Previous message: Brian Riis: "Re: C# vs. C++ Calling the overridden base class members from derived classes."
- In reply to: Julie: "Re: Is it poor design to have protected members in an abstract class?"
- Next in thread: Daniel T.: "Re: Is it poor design to have protected members in an abstract class?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Next message: Claudio Puviani: "Re: Merging mixed data sets"
- Previous message: Brian Riis: "Re: C# vs. C++ Calling the overridden base class members from derived classes."
- In reply to: Julie: "Re: Is it poor design to have protected members in an abstract class?"
- Next in thread: Daniel T.: "Re: Is it poor design to have protected members in an abstract class?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|