C++ What's the right way to run, in a superclass constructor, code that relies on lots of variables that the subclass overrides?

Question

Say I have a superclass that, when it initializes, wants to run some code that relies on a whole bunch of class variables that may or may not be overridden by a subclass in its constructor.

What's the accepted, clean way to code that?

I feel like I'm having a brain fart; this should be a standard, beginner usage of inheritance, but I can't figure it out.

e.g. say I have a superclass that represents a vehicle, and when it starts, I want to do a whole bunch of code where it processes, say, the load per axle or something (doesn't matter) but that code uses as inputs a bunch of parameters that exist for all vehicles (and thus exist in the superclass), say weight, length, numwheels, numaxles, maybe even complicated data structures defining how many wheels per axle, etc.).

The various subclasses (sportscar, bigrig, motorcycle), want to set the weight, length, numwheels, numaxles, etc. before the superclass does its processing.

---

Super::Super() {
    Process(var1_,var2_,var3_,var4_, ...);
}

Sub1::Sub1(): Super() {
    var1_ = <some math>;
    var2_ = <some math>;
    ...
}

doesn't work because the superclass Process() runs before the vars get set by the subclass. Right?

---

Super::Super(float var1, WackyDatastructureDef var2, int var3, WackyStruct2 var4, ...),
var1_(var1), var2_(var2), var3_(var3), ............... {
    Process(var1_,var2_,var3_,var4_, ...);
}

Sub1::Sub1(): Super(<some math>, <some math>, <some math>, <some math>, ......) {
    ....
}

looks horrible for obvious reasons. Also, it looks like a pain if I only need to override 2 out of the 20 default variable values.

---

Super::Super() {}
void Super::Init() {
    Process(var1_, var2_, var3_, var4_ ...... );
}

Sub1::Sub1(): Super() {
    var1_ = <some math>;
    var2_ = <some math>;
    ...

    Init();
}

looks the cleanest but I don't like it... it's weird to have to remember to call Init() at the end of all my subclass constructors. What if another programmer wants to subclass off my superclass and doesn't know my magic rule?

---

What's the right way to do this?

Answer 1

There are many ways to solve this issue (lack of virtual constructors in C++). Each one has its own benefits and drawbacks. Most common patterns to workaround this limitation:

• Pass all required arguments to base class constructor. This can be really annoying if you need more than few parameters. Code will be less and less readable and pretty hard to extend if requirements change. Of course it has a big benefit: it's not a workaround and everyone will understand it.

• Change your design (this may be the best thing to do but it may require a lot of work). If you need a lot of parameters then you may pack all arguments in separate class, it'll hold object status. Base class constructor will just accept one parameter of this type and it'll contain its status (or just its initialization data but this is another story). Its benefit is to keep design clear (no workaround like for first solution) but it may involve some complexity if this initialization token will evolve with its own class hierarchy.

• Add a public initialization method. Change your Init() method to public, it won't be invoke by derived constructors but by class users. This will allow you to add initialization code in each derived class (and initialization order is then controlled by implementation itself). This method is pretty old school and it requires users will call it but it has one big benefit: it's universally known and it won't astonish anyone. See this post here on SO for a small discussion about them.

• Virtual constructor idiom. See this article for a reference. It works as intended and you can make it easier to use with few template methods. IMO biggest disadvantage is that it changes how you manage inheritance and initialization when you create a new derived class. This may be boring and error prone and prolix. Moreover you change how a class is instantiated too and, for me, this is always annoying.

Few notes about second solution (from comments). If you apply this I see at least these options:

• Stupid entity (just data, no logic) that holds all required parameters.

• Encapsulate object status in a separate object. Object you pass from derived classes is not used and dropped but it'll be part of object.

In both cases you can have or not a parallel hierarchy for parameters (BaseParametersHolder, DerivedParametersHolder and so on). Please note that holder doesn't suffer from same problem of first solution (many arguments) because creation can be delegated to a private function (example is to illustrate concept, code is far to be nice):

class Derived : public Base 
{ 
public:
    Derived() : Base(CreateParameters()) 
    {
    }

private:
    ParameterHolder CreateParameters()
    {
        ParameterHolder parameters;
        parameters.Value = 1;
        parameters.AnotherValue = 2;

        return parameters;
    }
};

What to use? There is not an answer. I'd prefer to be consistent across code (so if you decide to use holders then use them everywhere, do not mix - for example - with v.i. idiom). Just pick proper one each time and try to be consistent.

Answer 2

Pass the relevant information up to the base class constructor.