Qt: стиль относительно сигналов / слотов

Question

У меня есть Объект X, который владеет (владеет указателями и инициализирует) Объекты Y1..10

Объект X имеет состояние, которое время от времени меняется. Я бы хотел, чтобы дочерние объекты (Y1..10) узнали о состоянии.

Как правило, это разрешимо с помощью указателя на родительский X из каждого дочернего объекта Y, чтобы он мог запрашивать свое состояние с помощью вызова метода, но я не хочу, чтобы объекты Y знали об объекте X, только его статус.

Мне было интересно, можно ли это реализовать с помощью сигналов / слотов:

Объекты Y будут определять сигнал, такой как:

void GetStatus(TheStatus & status);

Объект X соединит это со слотом, и при излучении объектом Y объект X запишет статус в заданную ссылку на состояние, чтобы объект Y получил его.

Таким образом, я могу иметь доступ к обновлениям состояния для объектов Y, но для этого им не нужно знать об объекте X.

Что вы думаете?

Answer 1

Похоже, вы думаете об этом задом наперед.Если объект X является тем, который хочет сделать «уведомление», то он должен излучать сигнал.Тогда у объектов Y будет слот для «приемников».

Таким образом, объект X должен излучать сигнал, например:

void X::statusChanged(TheStatus status);

Тогда объект Y будет иметь какой-то видсоответствующий слот.Предполагая надлежащие частные / публичные привилегии, любой объект - возможно, Z или даже сами X и Y - может использовать вызов QObject::connect, чтобы связать воедино совпадающие сигналы и слоты экземпляров объекта.Вы даже можете привязывать сигналы к сигналам.

Хотя вполне возможно, что вы можете назвать этот слот в Y как-то вроде onStatusChanged, что предполагает слишком тесную связь в вашем дизайне.В конце концов, слот может быть вызван как обычный метод.Так что, если вы можете думать о том, что слот на самом деле делает , а не называть его на основе его вызывающего, это может быть более разумным.

(Если функция foo()вызывая другую функцию, мы склонны присвоить этому новому имени bar() в зависимости от того, что он делает, вместо theFunctionCalledByFoo(), верно?)

Предпочтительно, как указал Мартин, чтобы попытаться сохранитьтипы, которые используют слоты довольно простые и отправляют их по значению.Если вы отправляете указатели и ссылки, то вы начинаете беспокоиться о времени жизни объектов, особенно в многопоточных сценариях, когда сигналы / слоты обрабатываются в очереди.

Хороший пример класса на основе уведомлений, с которым можно поиграть, это очень просто.чтобы понять, может быть индикатор выполнения:

http://developer.qt.nokia.com/doc/qt-4.8/qprogressbar.html#details

Answer 2

Это именно то, для чего предназначены сигналы / слоты.

Любое количество детей может подписаться на сигнал без кода отправителя, который должен знать об этом, отправителю даже не нужно иметь никаких получателей.для его сигнала.

В общем, я стараюсь, чтобы значения, посылаемые сигналами / слотами, были простыми, а не сложными объектами - таким образом проще вносить изменения отдельно.