Re: mandatory/optionally overridable virtual functions
Dilip wrote:
On Mar 2, 12:15 pm, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:
Dilip wrote:
struct AbstractBase
{
virtual void mandatory_func() = 0;
virtual void optional_func() { }
};
struct concretebase1 : public AbstractBase
{
virtual void mandatory_func() { }
};
struct concretebase2 : public AbstractBase
{
virtual void mandatory_func() { }
virtual void optional_func() { // do something cool }
};
on the face of it, it does seem natural but somehow I can't get it
out of my mind that I just keep adding virtual functions to
AbstractBase for every *specific* action I want to perform from one
of the derived classes.
Well, *that* doesn't seem sensible. Your motivation here is either
wrong or unclear.
Can I flesh this out a little bit? Lets say I have a client code that
does something like this:
void DoMe(AbstractBase* b1)
{
b1->mandory_func(); // everything is fine and dandy
b1->optional_func(); // no op for whichever classes don't need to
do this
}
If DoMe can be called with any of the concrete dervied classes as
parameter and only one of them needs to implement a particular
operation while the others no-op it out, how would I do it?
Well, when you put it like this, yes, that's the only way to do it.
However, why in your model your 'DoMe' function asks the AbstractBase
to perform an operation that only some derived classes should do?
This design doesn't seem sound. It would rather have sense to make
'DoMe' a virtual function of your base and let derived classes decide
whether they want to add to it or substitute it.
void AbstractBase::DoMe()
{
this->mandatory_func();
}
...
void SomeDerivedClass::DoMe()
{
this->AbstractBase::DoMe(); // do what the base is supposed to
this->someAdditionalStuff(); // and more...
}
If I have a lot of such operations I am concerned there
would be a virutal function bloat in AbstractBase.
What's a virtual function bloat? Why are you concerned with it?
I meant metaphorically -- like seeing a lot of unrelated virtual
functions scattered all over AbstractBase with no relation to each
other (making sense only to derived classes that choose to implement
them).
Ah. Then, yes, absolutely. You should not do that.
another quick question: in hierarchies like this do you make the dtor
of AbstractBase ordinary or pure virtual (with an empty impl)?
Depends on how you expect to destroy those objects. Since the class
already has some virtual functions, it won't cost more to make the
d-tor virtual as well, so I say, sure, make it virtual. No need to
make it pure, however, unless you want to make sure it's abstract and
you are expecting the purity of other virtual functions to be removed
due to whatever reason.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask