Re: Virtual private member functions
On Apr 2, 5:43 am, "Craig Scott" <audiofana...@gmail.com> wrote:
On Mar 28, 11:30 am, "Craig Scott" <audiofana...@gmail.com> wrote:
On the other hand, it could also be argued that the author of the b=
ase
class might want to prevent the virtual functions from being called=
in
any context other than the place the base class calls them. I can s=
ee
both sides, but I think we can be too hasty in just making them
private by default. It would seem that making them protected by
default might be more conservative.
I don't think you really need a "default". Design should decide
in each case.
Agreed. In the above context, by "default" I meant the choice a
designer might start with or apply when there seems no obvious choice
either way.
But that's a bit my point: the designer shouldn't start with a
preconceived choice. It's one of those things that requires
systematic consideration on a case by case basis. And there are
some basic rules which mean that according to the role of the
class, the "obvious" choice is different.
Most of the time, the virtual functions will be pure virtual in
an abstract base class.
This depends on the situation. Consider a (fairly common) case where
the intended design is for a base class to implement default behavior
for a "Template Method" design pattern.
The template pattern is a bit of an exception. Although it's a
good example of a case where the virtual functions would almost
certainly be private, you're right that they will often not be
pure virtual, but will provide a default implementation instead.
It might leave some pure
virtual, others with default implementations. Subclasses then override
just the pure virtual ones and then only those with default
implementations that they want to customize. Such an arrangement would
seem particularly well-suited to scientific or mathematical
applications where algorithms are often derivatives or customizations
of other similar ones.
It's also widely used in GUI's, where a virtual function is used
to obtain various display parameters, and there is almost always
a default version, which gives a default appearance.
In such cases, if the class has
invariants, or defines any sort of contract, the functions
should probably be private.
Why? If a subclass calls the base class implementation as part of its
own,
There are special cases where that's appropriate (someone
already mentionned them, I think---things like serialization),
and of course, in such cases, the virtual functions should be
protected. But such cases are the exception, not the rule.
Most of the time (I'd say over 90%), the base class will be
abstract, with only pure virtual functions, and there will be
only a single layer of inheritance.
More generally, if a class is responsible for ensuring the class
invariants (i.e. it is an implementation, and not an abstract
interface), then it doesn't want any further derived class
overriding its functions (which aren't providing "default"
behavior, but are responsible for working together to ensure the
class invariants). One can easily imagine, for example, a class
which implements an interface using the template pattern, to
allow further customization. In that case, however, the final
derived class should *not* override any of the functions of the
interface, but only those functions provided by the derived
class for customization (and the two sets of functions should be
disjoint).
the base class implementation can still test its invariants and
the subclass is responsible for ensuring those invariants are not
violated on entry to that function. This would apply to the subclass
whether it was using the base class implementation or not (ie not
violate any of the base class invariants). Whether the author of the
subclass has access to the list of invariants assumed by the base
class is another question, usually one of documentation. ;)
I'd be interested in hearing about a pattern where this actually
occurs, and where it would concretely be used.
Otherwise (e.g. inversion of call
situations, like the visitor pattern or a callback in an
observer), there's really no point in not making them public.
Personal preference. Plenty of people argue for and against whether
having virtual functions in the public interface is good design
practice. I'll keep my nose out of that debate!
I'm probably the inventor of the "virtual functions should not
be public" theory:-). Except that I invented it to solve a
particular problem (programming by contract); if that problem
doesn't exist...
Others have picked up the idea, and made an absolute of it. Or
a silver bullet. But we all know that silver bullets don't
exist.
When a derived class provides an implementation, logically, most
of the time, you'd want to "finalize" the function, and not
allow any further derived class de redefine it. Your
implementation is part of how you maintain your class
invariants, and allowing a further derived class to replace it
with something else means that you can no longer be sure of
enforcing your contract.
Same as my comments earlier this post. More derived subclasses may
want to further refine the implementation.
You mean "more derived subclasses want to violate your
invariants". As I said earlier, I'd be interested in seeing the
relevant design pattern, and knowing what problems it solves,
and when it should be used. I often hear arguments like the
above, which sum up to "more flexibility". But flexibility to
do what? And I've never heard it get beyond such vague
affermations.
It would seem better to
implement your own subclass such that it worries about its own
invariants and those of any base classes.
The only way I can ensure my invariants is to ensure that my
functions are called, and not sometimes mine, sometimes those of
some unknown further derived class. The only time those of some
further derived class can safely be used is if I design my class
for them. Typically, this means that I'm using the template
pattern in my implementation of the original base class, but in
this case, I'll define a new set of virtual functions to be
called by me, in my implementation.
If anyone wants to further
subclass your own subclass and override your implementation, then they
become responsible for ensuring that all invariants of its base
classes (including your own) are enforced.
If my invariants involve private data, it's going to be
difficult for him.
C++ does not offer a way to
say "this virtual function cannot be overridden again in any further
subclass".
I know. It would be better if there were some way to do so. On
the other hand, you'll never manage to prevent all errors with
the compiler, and there is such a thing as documentation, and
code review to ensure that it is respected.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34