Replace the typical observer pattern to the Qt's signal and slot

[stampede]

In addition, it could be quite useful to declare pure virtual slot void Observer::update( Source * changedSource ) = 0; in Observer class, this way all observers will share the same interface for receiving updates.

observer (also a sub-class of QObject) will connect its slot to the emitted signal

Maybe its a little detail, but I'd leave management of Observers to Watched class. In typical observer pattern ("Gang of Four"), Watched object defines methods for adding and removing Observers, so creating connection could be a part of Watched::add(Observer * o) method (and Watched::remove(Observer* o) could simply call this->disconnect(o)).

[wysota]

In addition, it could be quite useful to declare pure virtual slot void Observer::update( Source * changedSource ) = 0; in Observer class, this way all observers will share the same interface for receiving updates.

You can use QObject::sender() instead.

Maybe its a little detail, but I'd leave management of Observers to Watched class. In typical observer pattern ("Gang of Four"), Watched object defines methods for adding and removing Observers, so creating connection could be a part of Watched::add(Observer * o) method (and Watched::remove(Observer* o) could simply call this->disconnect(o)).

If you wrap signals and slots in Observer API then what's the point of using signals and slots in the first place?

[stampede]

If you wrap signals and slots in Observer API then what's the point of using signals and slots in the first place?

Because maybe later someone will have to replace signals and slots with other notification mechanism. I know, it's only an exercise, anyway I think its good practice to hide implementation details whenever its possible (this applies to your remark with sender() as well, I know here it will work and OP's quesion was about QObject).

[wysota]

Because maybe later someone will have to replace signals and slots with other notification mechanism.

But then why use signals and slots at all? You are implementing a complete observer pattern api only to internally use some other mechanism that already implements the same behaviour. The whole point of using signals and slots is that it is a loosely coupled mechanism. If you wrap it in API that requires some dedicated interfaces then you lose this flexibility and you can use those interfaces directly.

[stampede]

Benefit of using signals&slots underneath Observer api could be to send update() notifications to observers in thread-safe manner easily.
Anyway I think our discussion doesn't help the OP at all

[wysota]

I think all the OP wanted was to get rid of additional classes implementing the Observer pattern and use signals and slots directly. All those methods listed in the original post are good candidates for signals.

[stampede]

My bad, looks like I've misunderstood the original post. Forget what I've written here, you were right from the beginning.