Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. would you make your business objects inherit from QObject? pros and cons?
QtWS25 Last Chance

would you make your business objects inherit from QObject? pros and cons?

Scheduled Pinned Locked Moved Unsolved General and Desktop
3 Posts 2 Posters 282 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • mbruelM Offline
    mbruelM Offline
    mbruel
    wrote on last edited by mbruel
    #1

    Hi,
    On my new project I'm hesitating to make my business objects inherit from QObject.
    In general business objects all derive from a main BusinessObject and they only store the data loaded from whatever source. And potentially some methods of computations. So until now, I've never derived those objects from QObject.

    Is it something you have done? you would do?

    I'm considering it today to make my life easier on a simple use case: to easily avoid dangling pointers in GUI elements using pointers on some business objects to draw. Especially when those business objects can be updated from an external source or even deleted.
    Deriving from QObject allows GUI elements to use QPointer instead of raw pointers and connect the QObject::destroyed signal to close or invalidate the GUI elements. BusinessObject could also have an updated() signal again connected in the GUI elements to force a redraw.

    What do you think about this approach?

    Instead I could use a Factory that would hold a map/hash of all the business objects with all the GUI elements they use and make sure any GUI who needs a handle on a business objects does it through that Factory. In that way GUIs elements could also easily be notified on update or deletion.

    Which approach would you encourage? for what reasons?

    1 Reply Last reply
    0
    • kkoehneK Offline
      kkoehneK Offline
      kkoehne
      Moderators
      wrote on last edited by
      #2

      It's common to also have 'business objects' derive from QObject. This allows them to be part of the QObject lifetime management, allows them also to use signals/slots, hook into the Qt translation system, be exposed to QML ... So why not?

      The disadvantages of Q_OBJECT and friends are that they have some memory overhead, which however only matter if you have hundreds of thousands or millions of them. There's also some compile time overhead due to moc calls, and moc doesn't work too well with multiple inheritance or C++ templates. Finally, QObject derived objects cannot easily be mem-moved or copied. But if these do not apply to you, I would go the easy route and rely on the benefits of QObject also for business objects.

      Hope this helps.

      Director R&D, The Qt Company

      1 Reply Last reply
      1
      • mbruelM Offline
        mbruelM Offline
        mbruel
        wrote on last edited by mbruel
        #3

        @kkoehne ok good to know. personnally I've never done it as they were in general pure data so no need to of signal/slots but if others do it, I might start doing it when it is relevant ;)

        1 Reply Last reply
        0

        • Login

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • Users
        • Groups
        • Search
        • Get Qt Extensions
        • Unsolved