Re: Best design for my classes to avoid code duplication?
"James Kanze" <james.kanze@gmail.com>
I wouldn't say that inheritance was invented for this, but using
inheritance to provide "custom" initialization is a more or less
standard C++ idiom, and hardly what one would consider
contorted.
Well, "contorted" may be the wrong word, I mean it leads to way more work
and way more complexity, if actually chosen.
Templates are an alternative solution. They have the
disadvantage that they can easily lead to code bloat, and that
to be effective, the initializations have to share a common
pattern; inheritance gives you a lot more freedom. On the other
hand, to use inheritance, you have to make everything needed by
the derived classes available somehow: either protected or via
an accessor function.
Exactly. In the described case it needs converting the concrete classes to
interfaces.
There's no universally correct solution,
but on the whole, I find that inheritance provides the simpler
solution most of the time.
Solution to what requirements? If you need runtime polymorphism, sure, you
go that way. If compile-time stuff is good, then it is a drag, and
disadvantage.
Care to show an example?
class Device
{
Protocol* my_protocol;
Layout* my_layout;
In the original case there was ProtocolA, ProtocolB, no generic Protocol was
mentioned usable that way. Certainly it is possible to design the syste
that way up front, or convert like that, but would you do it unless
necessary?
class SomeSpecificDevice
: private SpecificProtocol // inheritance to control
, private SpecificLayout // order of initialization.
, public Device
{
public:
SomeSpecificDevice() : Device( this, this ) {}
};
With what you're back to 'repeated code' the original question was
concerned. To make it good you go ahead to make that class a template, and
use like in Jerry's #1 variant.
But then is there a real point to do the split, and fidding with the base
instead of the direct approach? You certainly still may want a base
class, if there are parts independent of the variable elements.
the original mentioned just simple calls that is hardly code bloat -- if
that is a real concern (and the template visibly has fat functions that are
mostly indepentent, a few virtuals may be defined and the bulk moved to the
base.
But that adds complexity, so only if there is a good reason.
And in current C++ you can not inherit constructors, so how
that would be handled?
See above. It's a fairly standard idiom.
I'm certainly aware of this way, and used it too, thought something
different is meant.
Of course, you can easily combine the two, using a template for
the derived class (parametrized on the protocol and the layout).
The derivation still gives you the liberty of handling special
cases differently, however.
Sure.
The classes' "common functionality" is really common just
textually -- it invokes different functions on objects of
different types.
The original code looked to me more of something along the lines
of the strategy pattern. Where inheritance plays an important
role in the stragety classes.
IMO strategy, as defined in the original form is mainly used for
runtime-changing situations. Especially in C++, where the static cases are
handled better using 'policy' or 'traits'. To me strategy implies I want
to assembe and possibly change it at runtime.