Re: Something like a final method
On Mar 22, 3:11 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* Marcel M=FCller:
James Kanze wrote:
Right pattern, but you've inverted the actions:
class Interface
{
public:
int getStatus() const
{
return doGetStatus() ;
}
private:
virtual int doGetStatus() const = 0 ;
} ;
class AbstractBase : public Interface
{
public:
int getStatus() const
{
return currentStatus ;
}
private:
virtual int doGetStatus() const
{
return getStatus() ;
}
private:
int myStatus ;
} ;
Thanks! This is the best suggestion so far. The syntax for
the caller is symmetric without a performance impact. I
don't know why something like that did not come into my
mind.
Note that James' code is essentially the same as blaarg's.
Sort of. Blargg uses an explicit scope qualifier to short
circuit the virtual-ness; I just put the implementation in the
non-virtual function.
And what it means that
o.getStatus()
may perform a virtual or a non-virtual call depending on the
type of 'o'.
Which is what is wanted, I think. If the caller knows the type,
it gets the non-virtual; if it doesn't, it gets the virtual.
The code I presented does not suffer from that problem.
Yours may perform a virtual or a non-virtual call depending on
the name of the function being called.
I prefer my solution, but admittedly, that may be only because
I'm more used to it. In the original example in Barton and
Nackman, the function was operator[], however, and you can't
give that one a different name, and still have it work as an
operator.
It's a fairly standard pattern, I think.
At least I did not use it so far.
The pattern used in the Interface is standard, in the sense of
being quite common and established as "good" (it's a shame it
can't be used with Java).
The inversion of that pattern in AbstractBase, in order to
avoid virtual calls, is not standard.
It's standard in the sense that it's a documented and
established pattern. I'd argue that any competent C++
practitioner should be familiar with it, but judging from
discussions in other threads, that's likely just wishful
thinking on my part.
It means that (as with the code I presented, and any solution,
but it's in your requirements so can't be avoided)
1. the wrong implementation of getStatus can easily be called.
Possibly. Arguably, there should never be more than one
implementation in any given class.
And as noted above (not the case with the code I presented) it
means that
2a. one can not see by local inspection of call whether a call is non-v=
irtual
or not, and worse,
2b. if you have the wrong static type for an object, e.g.
AbstractBase& where the dynamic type is DerivedWithCustomStatus, th=
en a
cast is needed to get the correct virtual call.
Finally, (not the case with the code I presented)
3. by adding the status implementation directly in AbstractBase that
implementation is forced as baggage on derived classes using another
implementation,
My understanding was that that was the purpose of AbstractBase;
to provide a "partial" implementation common to a large number
of derived classes. A derived class that doesn't need or want
this implementation derives directly from Interface, not from
AbstractBase. (At least, that's the way the AbstractXxx are
used in the Java library.) On the other hand, I do like your
idea of separating the particular aspect of the implementation
out into a separate, mixin class, rather than taking an all or
nothing approach to the partial implementation.
which presumably there will be, otherwise the status
implementation can and should be hoisted up in Interface
(which should then perhaps be called something else).
I suspect that the model being used is the same as that in e.g.
javax.swing.Action/javax.swing.AbstractAction. But you're
right: in C++, there's no reason to force everything possibly
shared between the concrete classes into a single class---mixins
are a much better solution.
--
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