2011-12-23 4 views
0

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

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

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

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

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

void GetStatus(TheStatus & status); 

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

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

Как вы думаете?

ответ

1

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

Таким образом, Х объект должен быть излучающий сигнал, как:

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

+0

Я использую doBlah() для приемника, который реагирует на события, как кнопка нажмите и обновитеBlah() для обновления некоторой части gui –

+0

@MartinBeckett В строке выполнения есть 'setValue()', но я не знаю, лучше ли это или хуже, чем 'updateValue()'. «set» может показаться немного легким для функции, которая обновляет элемент GUI, но я вижу это в обоих направлениях. В любом случае это лучше, чем 'onValueChanged()' - который звучит так же, как имя для сигнала, как для слота. – HostileFork

+0

Не имеет значения, как вы их называете. Вам просто нужно иметь какое-то соглашение, чтобы держать функции сигнала/слота прямо в голове, потому что компилятор ничего не делает для его принудительного применения. –

1

Это именно то, для чего нужны сигналы/слоты.

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

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

Смежные вопросы