Design decision regarding Multiple-Inheritance problem

Andreas Pakulat apaku at gmx.de
Sun Aug 8 22:20:06 UTC 2010


Hi,

I've started to play around with splitting our kdevplatform libs into
non-gui and gui code. And I'm hitting a problem where I'm not sure which
solution is more plugin-writer-friendly.

For the background: Splitting the code means taking an existing library
and extracting the API from it that works without GUI code. Right now I
just have ICore, IPlugin and IPluginController (+UiXXX versions), but
the next step of splitting up shell into a gui and a non-gui part throws
up multiple-inheritance with QObject.

The reason is simple: the three interfaces subclass QObject to provide
signals, their ui-versions subclass the non-ui classes. And now I'd need
a subclass of the non-ui version (for the non-ui shell) and a subclass
of the ui-version (for the ui-shell). At the same time, the ui-shell
class should be a subclass of the non-ui shell one.

This won't work as we'd have 1 class inheriting QObject from two
different base classes, which QObject doesn't allow.

The two solutions I can think of right now are:

a) The interface-classes (ui and non-ui) are being set up as 'pure'
interfaces, i.e. no base-class. And the signals are simply abstract
virtual functions in the interfaces and only signals in the actual
implementations. One problem with that is that connect() won't work then
anymore, so we'd either need a toQObject() function on them, or cast it
manually.

b) create separate API tree's, one for non-gui code and the other for
gui code. This would mean that any code using the API needs to take care
of 'manually' choosing to either use the gui or non-gui API tree to do
something. For example the non-gui plugincontroller would only load
non-gui plugins. It also means duplicating some of the API (both non-gui
and gui-plugincontroller should have similar API).

Right now I'm leaning towards option a) as it seems to be a bit less
ugly, but I really don't like the toQObject (or manual dynamic_cast for
each connect)... 

Opinions? Other ideas how to solve this dilemma?

Andreas

-- 
You have no real enemies.




More information about the KDevelop-devel mailing list