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 |
|QObject || |
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.