LINUX.ORG.RU

Расшарить объект между разными частями программы

 , ,


0

1

Здравствуй, ЛОР! Проблема такова: имеется группа классов, которые отвечают за GUI. Через него формируются запросы. Когда объект обработает запрос, то и результаты естественно передаются GUI. Как лучше сделать объект доступным для разных классов GUI?

★★★★★
Ответ на: комментарий от pylin

В Qt есть синглтон «из коробки» - qApp. Если ты сам делаешь свой QApplication, то можно отсюда и плясать.

Но вообще, синглтон - это глобальная переменная в красивом фантике, т.е. кака.

kulti ★★
()

Сигналы и слоты же, возможно, паттерн observer. А вообще хотелось бы уточнить, как объекты связаны с GUI - какую-нибудь метафору происходящего можно озвучить?

quiet_readonly ★★★★
()
Ответ на: комментарий от quiet_readonly

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

pylin ★★★★★
() автор топика

имеется группа классов, которые отвечают за GUI

Передавай ссылку/указатель в эти твои классы. Синглтон не стоит делать.

anonymous
()
Ответ на: комментарий от anonymous

вот кстати к варианту передавать указатель и склонялся

pylin ★★★★★
() автор топика
Ответ на: комментарий от pylin

Параметры можно содрать с GUI и записать в структуру, заодно ещё и валидацию прикрутить можно - чтобы при при вводе невалидных данных в одно из полей где-то в QLabel показывалось описание причин невалидности, а кнопка «отправить» становилась неактивной.

Структурку можно передать объекту, делающему запрос, потом ещё одну структурку объявить для полученного ответа. Слот

void onRespone(DBResponce const& res);
у класса GUI, сигнал
void responceReady(DBResponce const& res);
у класса, отвечающего за DB.

Если речь идёт о многопоточности, то вместо ссылки достаточно передать указатель и владение объектом - т.е. отправитель объект-параметр создал через new, получатель его удаляет через delete или оборачивание в умный указатель.

quiet_readonly ★★★★
()
Ответ на: комментарий от quiet_readonly

Что ж вроде весьма неплохой вариант, попробую его.

pylin ★★★★★
() автор топика
Ответ на: комментарий от kulti

т.е. кака.

Дай угадаю. Ты еще goto не любишь. Да?

SSZB
()

Как насчёт модного MVC?

Гуи классы — вью. Объект, обрабатывающий запросы — модель. Остаётся добавить контроллер, т.е. класс, который будет хранить ссылки на модель и вьюху и выступать посредником между ними.

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

Apple-ch ★★
()

Как насчёт command/processor pattern? В комманду запихиваешь всё что тебе надо и отправляешь куда надо (твоему гую(вью)). Гуй получает, показывает. Нажал кнопочку, запихнул в комманду, отправил тому, что обрабатывает её. И так далее.

invy ★★★★★
()
Ответ на: комментарий от Apple-ch

Классический MVC хорош для одной модели и нескольких представлений, а также для согласования UI и логики в отдельных потоках - потому его и используют на айфонах, да и на андроидах, наверное. У ТСа наоборот, один интерфейс и то ли ряд запросов, то ли один запрос.

quiet_readonly ★★★★
()
Ответ на: комментарий от invy

Я это и писал выше ;) Только вы зачем-то упираете название паттерна, а ТСу нужны нюансы его реализации в плюсах. Хотя название ему тоже пригодится - в будущем.

quiet_readonly ★★★★
()
Ответ на: комментарий от quiet_readonly

Классический MVC хорош для одной модели и нескольких представлений

Внезапно, в ОП описана именно такая ситуация:

Как лучше сделать объект доступным для разных классов GUI?

То есть одна модель (объект, отвечающий за взаимодействие с БД) и много представлений.

Apple-ch ★★
()

Если объект только один, больше уже точно не будет - синглтон.

Если могут появиться другие обработчики - курите всякие разные паттерны проектирования.

А вообще - лучше объединить группу классов GUI в один, который уже будет общаться с обработчиком запросов (связанность будет ниже). Или реализовать MVC, как предлагали выше, но это затратней.

unfo ★★★★★
()
Ответ на: комментарий от bjorn

теоретически(по стандарту) такого термина нет, практическая реализация с таким поведением - есть. Вопрос прежний.

Jetty ★★★★★
()
Ответ на: комментарий от slackwarrior

Нет, мы не будем задавать этот вопрос, ответ предельно очевиден. Поэтому вы будете отвечать на исходный вопрос.

Jetty ★★★★★
()
Ответ на: комментарий от anonymous

Хм... вот оно как... Понятно, спасибо.

Jetty ★★★★★
()
Ответ на: комментарий от slackwarrior

Пока ты занимаешься словоблудием, анонимус уже ответил на вопрос, что весьма любезно с его стороны... А вот твое участие весьма показательно - «в интеренете кто-то неправ!!!!!!»

Jetty ★★★★★
()
Ответ на: комментарий от Jetty

НетЪ! Я тебя всего лишь попросил «приоткрыть зовесу страшной тайны», что именно ты понимаешь под «статическим классом» в С++, когда тебе вполне резонно сказали, что их в С++ нет :) Отказ твой был весьма нелюбезен, что не менее показательно. Трудно в теги [code /]? «Поэтому вы будете отвечать на исходный вопрос.» (с) В глаза смотреть!!!111

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от Jetty

теоретически(по стандарту) такого термина нет, практическая реализация

«Пока ты занимаешься словоблудием» (ТМ)

теоретически (по стандарту)

И эти люди запрещают нам заниматься словоблудиемНет ты! :) Изображай дальше рыцаря пафоса, смешно получается.

slackwarrior ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.