UNISA Chatter – Design patterns in C++ Part 2: Composite Pattern

See UNISA – Summary of 2010 Posts for a list of related UNISA posts. Continued from UNISA Chatter – Design patterns in C++ Part 1: Visitor Pattern.

QT and Environment Summary

The following is a summary of findings as I worked through the course related book. See the summary post for details on the book.

Terminology Description Example

QObjects are intended to represent real-world “things” with an identity. Things to note about QObject:

  • Copy constructor is not public
  • Cannot be passed by value
  • Cannot be copied
  • Can have one parent and many children
  • Automatically destroys all its children
QObject Reparenting Reparenting means that a QObject changes its parent from A to B, which implicitly adds the QObject to B’s list of children and removes it from A’s list. // Create dmo object with parent == objA
QObject objDemo = new QObject(objA,”Demo ID”);
// reparent from objA to objB
QObject Copy Constructor Copy  constructor is not public, to enforce the non-copy rule.
QObject Children QObject provides functions named findChildren() to allow users to find children in the list of children, whereby template parameters are used. QList <DemoObject*> demoList = objA.findChildren<DemoObject*>();
Signal & Slot A signal is raised when an event occurs. A slot is a function that is called in response to a signal.

void objDemo::slotFx ( int value )
   // zerovalue is a signal of objDemo
   if (value = 0) emit zerovalue();
   // toomuch is a signal of objDemo
   if (value >100) emit toomuch();
Transmission of Data Arguments passed in the emit statement are accessible as parameters in the slot function and the argument list is therefore the way to pass data from one object to another using slots and signals. See above.
Value vs. Object Type Value types occupy contiguous memory, can be compared and copied. Objects are heavier weight and have an identity. QObject cannot be passed by value … see QObject above.  

Design Pattern Summary

Terminology Description
Pattern: Composite
  • Structural design pattern
  • Facilitate building complex (composite) objects from simpler (component) objects and representing the whole-part hierarchies as tree-like structures. Think of an airport, made up of planes, which in turn are made up of plane parts.


The illustration shows the sample I implemented as part of my assignments, which I am happy to share if you are interested. The journey through QT and the QT IDE have been interesting, BUT I long to return to Visual Studio 2010 with its productivity, reliability … guess familiarity rules 🙂


The one thing I need to highlight for those on this course is to ensure that you do not forget to define the Q_OBJECT macro in your class definitions. If you omit this macro there are no warnings, however, run-time behaviour is VERY odd.

If you skip the Q_OBJECT macro, the following logic will not, as expected, return only MailFolder objects, but all objects within the hierarchy … which obviously results in some interesting exceptions.


As soon as you define the Macro, the world is wired up correctly and the code behaves as expected … had me going for a while 😐

… next we will explore the Generics and Templates, keeping an obvious eye on QT.

Comments (2)
  1. Ryno says:

    Can you provide the full example of this. (MailItem, Mail and Mailfolder classes and implementation) I thought that the calss MailItem(Component) will have the definition as you specified above and that the class Mail will extend MailItem and not QObject?

  2. Well spotted Ryno.

    The diagram shows the design for the final solution, whereas the Mail class definition is an extract from my test environment. As part of my exploration and testing I initially used QObject and its collection features in place of Item, Composite and MailItem as per the diagram.

    I will share the final solution as soon as the assignments are submitted and can then be freely shared.

Comments are closed.

Skip to main content