Question

I’m building a fairly large plugin-driven app in my spare time, and have come across a show stopping design flaw. My app uses policy/traits based design, but because I use Qt it is done just through MI (rather than templates and MI). Some of these classes are pure virtual and some perform rather critical functions under the hood that the end-user should never touch.

My problem is that some of these classes require signals/slots and therefore derive from QObject, no problem I can just virtually inherit from it. However, the problem I have is when I want derive from a Qt class and then extend it with one or more of my traits, eg:

class Sy_abstractGLViewport : public QGLWidget, public Sy_saveable, public Sy_abstractObject
{
    ...
}

Here QGLWidget is derived from QObject, but not virtually, causing ambiguity problems.

I’ve considered a Bridge pattern where I make for example my Sy_saveable pure virtual and then derive a Sy_saveable_imp from it that contains the actual implementation. Then use that for my Sy_abstractGLViewport via aggregation.

This to me seems rather unprofessional, because the app is plugin based, it’s a bit of a PITA for my future plugin writers to ‘hook up’ all the interface methods to the aggregated instance. I can’t even automate it through macros because the end-user may want to override a method.

Has anyone a pattern to solve this issue? Or a pattern that doesn’t require MI but gives me the same flexibility? This my personal hobby project, I don’t mind doing a lot of refactoring – I want to do it right.

Answer 1

You can’t inherit from multiples clasess that inherit QObject.

Try using composition instead of inheritance. See composition over inheritance.

You can also try using Q3Signal class. Although it belongs to old QT3 according to QT doc :

The Q3Signal class can be used to send signals for classes that don’t
inherit QObject.