Subject: Re: Code guidelines, state of C++ compilers used, and generalC++comments
From: Mike Nordell (tamlin@algonet.se)
Date: Tue May 09 2000 - 11:22:12 CDT
Leonard Rosenthol wrote:
>At 8:13 AM +0100 5/9/00, Mike Nordell wrote:
>>Since you mention "numerous examples", would you care to share at
least
>>two of these "perfectly acceptable and correct" eamples with us?
>
>Sure...
>
>In a GUI framework, you might have a base class of something
>like CControl which would have the member variable of the OS's
>"control handle", while all the specific subclass would reference it.
>It wouldn't make any sense for each subclass to have their own "copy"
>of that same member variable since all subclasses need it.
This is no argument for allowing protected member variables. This is an
argument for allowing data in a baseclass.
>Same is true in a set of stream classes where you might have
>common stream attributes (length, position, etc.) in the base rather
>the copied to each subclass.
Same here. I'm not pushing the point "baseclasses should have no data",
I'm pushing the point that "class data should always be private".
These two point neither justify nor arguing for allowing
protected class data members.
>>Just to give a glimpse of the maintenance nightmare we're facing, I
found
>>out that baseclass (protected) member variables got
initialized/replaced
>>by subclasses (in AbiWord).
>
>Initialization should take place during construction by
>calling the base classes constructor:
Yes, initialization should be done in the constructor if it's not agreed
upon to use two-step construction (c'tor + init() call). But it don't
happen here because the member variables of the baseclass(es) aren't
private.
>So what's your suggestion? Make them all private, and create
>inline accessor functions?
Yes. To write e.g. 'getHwnd()' instead of 'm_hWnd' is no great burden for
the increase in maintainability it gives. Should one in the future decide
to replace that mechanism by something else, the baseclass is free to do
whatever refactoring it wants to. Derived classes should only depend on
their baseclasses public and protected _interfaces_, not their
implementation-specifics.
When designing interfaces there's one principle that's really good to
think about:
- Interfaces shall be small and complete.
(I don't think "small" was the word I was looking for, but it works)
If someone feels the need to probe a baseclass' data directly, perhaps
that baseclass' interface isn't "complete".
/Mike - please only post follow-ups to the list
This archive was generated by hypermail 2b25 : Tue May 09 2000 - 10:21:59 CDT