Помогите с архитектурой приложения

[Edynchik]

Добрый день! Возникла следующая проблема, экспериментальным путем доказано что моя архитектура не работает. Предложите, пожалуйста, альтернативу. В общем зада следующая. Есть канал из которого необходимо считывать информацию, и отображать на экране. Я ее решил следующим образом, создал класс формы,в нем еще два класса. Один для считывания из канала (отдельный класс, потому что каналов несколько) и класс отображения (графиков отображения может быть тоже несколько). Когда по таймеру из канала считалась информация посылается сигнал в форму у которого параметром выставлена необходимая для записи инфа. Класс отображения по таймеру выдает сигнал в форму - запрос информации. И форма соответственно обработав этот сигнал, передает сигнал содержащий данные для отображения. И все вроде отлично работало до момента работы деструктора: возникает ситуация в которой сигнал с запросом инфы для отображения уже послан,срабатывает деструктор класса отображения и соответсвенно рисовать уже некуда...как следствие крах. Что можно придумать?

[Bepec]

Это ваша тема про осциллографы? Что-то такое там было

Переусложнённая у вас архитектура.

Моё видение:
1) класс главного окна приложения.
2) класс отображения графика.
3) класс приёма информации (мб даже в отдельном потоке ).

Архитектура проста - 2)/3) существуют связками. Точнее 2) в конструкторе создаёт привязанный к себе 3).

3) получает информацию, отсылая сигналом данные в 2). 2) получает данные и отображает их.

При закрытии 2) сначала уничтожается  3) и после чего удаляется 2).

PS ох блин понаписал я самому бы потом понять.

[Edynchik]

Это ваша тема про осциллографы? Что-то такое там было

Переусложнённая у вас архитектура.

Моё видение:
1) класс главного окна приложения.
2) класс отображения графика.
3) класс приёма информации (мб даже в отдельном потоке ).

Архитектура проста - 2)/3) существуют связками. Точнее 2) в конструкторе создаёт привязанный к себе 3).

3) получает информацию, отсылая сигналом данные в 2). 2) получает данные и отображает их.

При закрытии 2) сначала уничтожается  3) и после чего удаляется 2).

PS ох блин понаписал я самому бы потом понять.

да все таже тема...пытался как то реанимировать, но бестолку...в ваших словах определенно есть логика...хм а есть еще тонкие моменты в будущем о которых можете предупредить...

[kambala]

И все вроде отлично работало до момента работы деструктора: возникает ситуация в которой сигнал с запросом инфы для отображения уже послан,срабатывает деструктор класса отображения и соответсвенно рисовать уже некуда...как следствие крах. Что можно придумать?

можно добавить класс-менеджер, который будет перенаправлять сигналы в объект отображения если он существует

[Bepec]

Я думаю, что вашу программу можно реанимировать спокойно и неспешно. Но увы, нужно это смотреть на работающем проекте

[Edynchik]

Это ваша тема про осциллографы? Что-то такое там было

Переусложнённая у вас архитектура.

Моё видение:
1) класс главного окна приложения.
2) класс отображения графика.
3) класс приёма информации (мб даже в отдельном потоке ).

Архитектура проста - 2)/3) существуют связками. Точнее 2) в конструкторе создаёт привязанный к себе 3).

3) получает информацию, отсылая сигналом данные в 2). 2) получает данные и отображает их.

При закрытии 2) сначала уничтожается  3) и после чего удаляется 2).

PS ох блин понаписал я самому бы потом понять.

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

[Bepec]

Ничто не мешает посылать второй сигнал допустим.

Но лучше тогда менеджера создавать.

[Old]

Ничто не мешает посылать второй сигнал допустим.

Но лучше тогда менеджера создавать.

Зачем? К одному сигналу могут быть привязаны стопитсот получателей.

[Bepec]

Потому что менеджер - это хорошо. А 100500 связанных сигналов - это плохо для отладки.

[Old]

Аргументы будут?

[Edynchik]

Ничто не мешает посылать второй сигнал допустим.

Но лучше тогда менеджера создавать.

Не могли бы описать работу класса менеджера? То что управлять, понятно...а далее...

[Old]

Не могли бы описать работу класса менеджера? То что управлять, понятно...а далее...

Хороший вопрос.