Question

I need to use C++. C++11 would be interesting, but I’d prefer without. I have the following class structure.

class Wheel { /*...*/ };
class MtbWheel : public Wheel { /*...*/ };

class Bike { Wheel front_wheel; };
class Mountainbike : public Bike { MtbWheel front_wheel; };

Now, this completely works: The Mountainbike overrides front_wheel, and thus can use an MtbWheel. Softwaretechnically, I am not happy, though.

• What I would prefer is disallowing to override front_wheel, or at least restrict overwriting by classes that do not inherit class Wheel.
• Instead of overriding front_wheel, I’d like only to “add” properties to it.

EDIT: Is there a solution without virtual functions, but with templates instead?

Answer 1

Your front_wheel member in Mountainbike class does not override front_wheel, it hides it. Mountainbike class actually has two front_wheel members, but the one from the Bike class is hidden by the one declared in Mountainbike. Meaning that if Bike accesses front_wheel, it will access an object of type Wheel, while when Mountainbike accesses front_wheel, it will access an object of type MtbWheel – but these two wheel objects don’t know of each other!

Better OO design would be to make front_wheel e.g. a pointer in Bike (or even better a smart pointer), and initialize it in the constructor of Mountainbike to hold an object of a class derived from Wheel which fits best to Mountainbike. That way, when accessing front_wheel, one way or the other virtual functions come into play of course.

An alternative solution, as per Steve Jessop’s suggestion in the comments below, making use of templates instead of using polymorphism, would be:

class Wheel { /*...*/ };
class MtbWheel : public Wheel { /*...*/ };

template <typename WheelType>
class Bike { WheelType front_wheel; };

class Mountainbike : public Bike<MtbWheel> { /* ... */ };

That way, no virtual functions are involved when operating on front_wheel. There are some points to consider with such a solution, however:

• For each different WheelType you use Bike with, separate code will be created; if you have many different such types, this might result in code bloat.
• If you have more than one class derived from Bike with different WheelType parameters, they do not have the same base class (see Steve Jessop’s comment, and point 1), and therefore also can’t be accessed polymorphically.
• You can not enforce an explicit interface on the WheelType being passed as template parameter to Bike; only the implicit interface is defined by the methods and members used from Bike. That should be no problem however, since the compiler can still verify that implicit interface.