QT: Is it a good idea to base my domain objects on QObject?

Question

Hi,

I'm reasonably new to using the QT framework in combination with C++. I was wondering: Is it a good idea to base my domain classes on QObject? Or should I only do this for classes higher up in the hierarchy? (closer to the user interface level). The QT documentation isn't clear on this:

Taken from the QT documentation:

The meta-object system is a C++ extension that makes the language better suited to true component GUI programming.

Obviously I want to build my application in a nice well structured way. Over the past few days I have been browsing through the QT documentation in order to find an answer to this question. I don't want to make some elementary mistake which will make my application limp for all eternity ;-).

I have already looked at the basic documentation for QObject and the Qt Object model. I also found a freshmeat article which helped but didn't really help me reach a conclusion. Something else that confuses me is that QT itself doesn't seem to be consistent on this matter because not all QT classes use QObject as a base class.

The advantages of using QObject as a base class as I see them:

• Hierarchy
• Signals and slots
• Properties
• Being able to use guarded pointers
• Internationalization

However, I don't require any of these functionalities in most of my domain classes. Is there a best practise rule for this? Or should the rule be: use it if you require any of the points mentioned above?

Hope I didn't make this too confusing :-)

Answer 1

"Use it if you require any of the points mentioned above" - it is difficult to say better. There is no reason to add unnecessary functionality to every class. Think also about classes defined in shared libraries: they can be used by non-Qt clients, if you don't derive them from QObject.

Answer 2

This issue isn't 'as big' as you might think. It really doesn't matter all that much. I'd say if you do or don't it really won't be all that different. So, as a rule of thumb, don't, just to make things simpler. If, however, you need signal-slots or anything Qt realated, go ahead, it doesn't cost all that much anyway.

Answer 3

In general, unless there is a "compelling need," you are better off keeping your domain classes "vanilla." That gives you the most flexibility in the future (e.g. re-using them in a non-Qt environment).

Answer 4

I would almost like to answer the opposite of your question, it is not a bad idea. Whether they should be QObjects depends on you needs. For me the ability to use properties and reflection is almost worth more that signal and slots. QMetaObject can be very helpful to for flexible programming strategies

Answer 5

I'm learning (reading document) but not started using Qt yet, here is my opinion on your question. It's always good to have a single root object (CObject in MFC, TObject in VCL), so define a your own root object, such like YourOwnRootObject. If you think you need QObject most time, make YourOwnRootObject inherite from QObject, otherwise, leave YourOwnRootObject alone until you need QObject.

Answer 6

There is a good reason not to inherit from QObject unnecessarily, and it's right there in the documentation.

No copy constructor or assignment operator

QObject has neither a copy constructor nor an assignment operator. [...]

The main consequence is that you should use pointers to QObject (or to your QObject subclass) where you might otherwise be tempted to use your QObject subclass as a value. For example, without a copy constructor, you can't use a subclass of QObject as the value to be stored in one of the container classes. You must store pointers.