|
Название: Помогите с архитектурой приложения Отправлено: Edynchik от Июль 17, 2013, 16:31 Добрый день! Возникла следующая проблема, экспериментальным путем доказано что моя архитектура не работает. Предложите, пожалуйста, альтернативу. В общем зада следующая. Есть канал из которого необходимо считывать информацию, и отображать на экране. Я ее решил следующим образом, создал класс формы,в нем еще два класса. Один для считывания из канала (отдельный класс, потому что каналов несколько) и класс отображения (графиков отображения может быть тоже несколько). Когда по таймеру из канала считалась информация посылается сигнал в форму у которого параметром выставлена необходимая для записи инфа. Класс отображения по таймеру выдает сигнал в форму - запрос информации. И форма соответственно обработав этот сигнал, передает сигнал содержащий данные для отображения. И все вроде отлично работало до момента работы деструктора: возникает ситуация в которой сигнал с запросом инфы для отображения уже послан,срабатывает деструктор класса отображения и соответсвенно рисовать уже некуда...как следствие крах. Что можно придумать?
Название: Re: Помогите с архитектурой приложения Отправлено: Bepec от Июль 17, 2013, 16:39 Это ваша тема про осциллографы? Что-то такое там было :)
Переусложнённая у вас архитектура. Моё видение: 1) класс главного окна приложения. 2) класс отображения графика. 3) класс приёма информации (мб даже в отдельном потоке :) ). Архитектура проста - 2)/3) существуют связками. Точнее 2) в конструкторе создаёт привязанный к себе 3). 3) получает информацию, отсылая сигналом данные в 2). 2) получает данные и отображает их. При закрытии 2) сначала уничтожается 3) и после чего удаляется 2). PS ох блин понаписал я :D самому бы потом понять. Название: Re: Помогите с архитектурой приложения Отправлено: Edynchik от Июль 17, 2013, 16:45 Это ваша тема про осциллографы? Что-то такое там было :) Переусложнённая у вас архитектура. Моё видение: 1) класс главного окна приложения. 2) класс отображения графика. 3) класс приёма информации (мб даже в отдельном потоке :) ). Архитектура проста - 2)/3) существуют связками. Точнее 2) в конструкторе создаёт привязанный к себе 3). 3) получает информацию, отсылая сигналом данные в 2). 2) получает данные и отображает их. При закрытии 2) сначала уничтожается 3) и после чего удаляется 2). PS ох блин понаписал я :D самому бы потом понять. да все таже тема...пытался как то реанимировать, но бестолку...в ваших словах определенно есть логика...хм а есть еще тонкие моменты в будущем о которых можете предупредить... Название: Re: Помогите с архитектурой приложения Отправлено: kambala от Июль 17, 2013, 17:50 И все вроде отлично работало до момента работы деструктора: возникает ситуация в которой сигнал с запросом инфы для отображения уже послан,срабатывает деструктор класса отображения и соответсвенно рисовать уже некуда...как следствие крах. Что можно придумать? можно добавить класс-менеджер, который будет перенаправлять сигналы в объект отображения если он существуетНазвание: Re: Помогите с архитектурой приложения Отправлено: Bepec от Июль 17, 2013, 22:05 Я думаю, что вашу программу можно реанимировать спокойно и неспешно. Но увы, нужно это смотреть на работающем проекте :D
Название: Re: Помогите с архитектурой приложения Отправлено: Edynchik от Июль 18, 2013, 12:53 Это ваша тема про осциллографы? Что-то такое там было :) изначально у меня так и было сделано, только пришлось от нее отказаться ввиду того, что информация из одного канала может понадобится нескольким классам отображения...т.е. я сделал сохранение данных из канала в классе формы...Переусложнённая у вас архитектура. Моё видение: 1) класс главного окна приложения. 2) класс отображения графика. 3) класс приёма информации (мб даже в отдельном потоке :) ). Архитектура проста - 2)/3) существуют связками. Точнее 2) в конструкторе создаёт привязанный к себе 3). 3) получает информацию, отсылая сигналом данные в 2). 2) получает данные и отображает их. При закрытии 2) сначала уничтожается 3) и после чего удаляется 2). PS ох блин понаписал я :D самому бы потом понять. Название: Re: Помогите с архитектурой приложения Отправлено: Bepec от Июль 18, 2013, 15:47 Ничто не мешает посылать второй сигнал допустим.
Но лучше тогда менеджера создавать. Название: Re: Помогите с архитектурой приложения Отправлено: Old от Июль 18, 2013, 15:50 Ничто не мешает посылать второй сигнал допустим. Зачем? К одному сигналу могут быть привязаны стопитсот получателей.Но лучше тогда менеджера создавать. Название: Re: Помогите с архитектурой приложения Отправлено: Bepec от Июль 18, 2013, 19:27 Потому что менеджер - это хорошо. А 100500 связанных сигналов - это плохо для отладки.
Название: Re: Помогите с архитектурой приложения Отправлено: Old от Июль 18, 2013, 19:51 Аргументы будут? :)
Название: Re: Помогите с архитектурой приложения Отправлено: Edynchik от Июль 18, 2013, 20:00 Ничто не мешает посылать второй сигнал допустим. Не могли бы описать работу класса менеджера? То что управлять, понятно...а далее...Но лучше тогда менеджера создавать. Название: Re: Помогите с архитектурой приложения Отправлено: Old от Июль 18, 2013, 20:17 Не могли бы описать работу класса менеджера? То что управлять, понятно...а далее... Хороший вопрос. :) |