Well, your code already relies on the fact that in DerivedClass the vector mKeys contains only SpecialKey pointers, as dynamic_cast will return 0 if the cast isn’t typesafe and your code segfaults on line #10. Assuming that, just replace dynamic_cast with static_cast, which can be used to downcast as well.

If your vector contains both, BaseKey and SpecialKey pointers (which your example does, as BaseClass::BaseClass(), which you forgot to call by the way, pushes a BaseKey) you will have to do some kind of runtime type checking. You either use RTTI / dynamic_cast or QVariant.

If you want no cast at all you will have to make sure that every pointer in the vector shares the same interface, which means moving SpecialKey::DoSomeThingSpecial() to BaseKey or having DerivedClass an additional vector which contains the SpecialKey pointers and BaseClass::mKeys contains only BaseKey pointers (and having an additional loop), with the downside of keys beeing pressed in a different order than they were pushed.

Please look at the vistor pattern
http://en.wikipedia.org/wiki/Visitor_pattern

Lukas: I just posted some psuedo code, this is no production code :). I want to remove the casts as it doesn’t feel good… And to use the same interface feels also strange because why should the BaseKey have a DoSomethingSpecial method that doesn’t do anything..

I have also seen other ‘solutions’ that override the mKeys members in the derived: QVector<SpecialKey*> mKeys…. But again this doesn’t feel like right.

Mikael, I will have a look at the visitor pattern. I was looking for a pattern that would solve my problem but I cannot really figure out which one to use… To make things more complicated I also have the derived class use some methods of the baseclass.

Maybe the factory method pattern [en.wikipedia.org] is what your looking for.

Having a single collection containing elements with different interfaces always results in some kind of differentiation at runtime, be it dynamic_cast, QMetaType::type() or a vtable look-up as in the visitor pattern. If you don’t want the differentiation at runtime you either have to

• have all the elements in the collection sharing the same interface or
• have a separate collection for each interface.

There is no way around that.

Even when using the visitor pattern your elements have to share the same interface (although a smaller one). I don’t know how diverse your BaseKey dervived classes are, but the visitor pattern could at least prevent your base class from beeing the least common multiple of all your derived classes – at the cost of another layer of complexity.

What is your concern? Performance? Maintainability?

I possibly would use a combination if I had to eliminate the dependency of a runtime type information system and the complexity of the visitor pattern:

The switch can be replaced with a condition if every key needs to implement just one action. Won’t win a design price, but I haven’t seen a compromise yet that does.

bkamps wrote:

I have also seen other ‘solutions’ that override the mKeys members in the derived: QVector<SpecialKey*> mKeys.

You cannot overload or override member variables in dervied classes, you just hide them – and you end up with two seperate member variables.