I have an Object X which owns (owns pointers to and initializes) Objects Y1..10
Object X has a state that changes from time to time. I'd like the child objects (Y1..10) to become aware of the state.
Typically, this is resolvable by having a pointer to the parent X from each Y child object, so that it can query its status via a method call, but I don't want the Y objects to be aware of object X, just its status.
I was wondering if this could be implemented with signals/slots:
The Y objects will define a signal such as:
void GetStatus(TheStatus & status);
The X object will connect this to a slot, and when emitted by a Y object, object X will write the status onto the status reference given so that the Y object gets it.
This way I can have status updates be available for Y objects, and yet, they do not need to be aware of object X to achieve that.
What do you think?
It looks like you are thinking of it backwards. If the X object is the one that wants to do the "notifying", then it should be emitting the signal. Then the Y objects would have the slot to be the "receivers".
So X object should be emitting a signal, like:
void X::statusChanged(TheStatus status);
Then the Y object would have some kind of matching slot. Assuming proper private/public privileges, any object—perhaps Z or even X and Y themselves—could use the QObject::connect call to tie together matching signals and slots of object instances together. You can even tie signals to signals.
While it's possible that you could call that slot in Y something like onStatusChanged, that suggests a little too tight a coupling in your design. After all, a slot can be called just like a regular method. So if you can think of what the slot actually does rather than naming it on the basis of its caller, that can be more sensible.
(If a function foo() calls another function, we tend to give that a new name bar() based on what it does, instead of theFunctionCalledByFoo(), right?)
It's preferable as Martin pointed out to try and keep the types that slots use fairly basic and send them by value. If you send pointers and references then you get into worries about object lifetimes, especially in multithreaded scenarios where the signals/slots are processed in a queue.
A good example of a notification-based class to play with that's simple to understand might be the progress bar:
http://developer.qt.nokia.com/doc/qt-4.8/qprogressbar.html#details