crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )

 
Ответить в данную темуНачать новую тему
> Вопрос архитектуры приложения
call_me_Frank
  опции профиля:
сообщение 23.3.2012, 12:21
Сообщение #1


Студент
*

Группа: Участник
Сообщений: 73
Регистрация: 20.10.2010
Пользователь №: 2129

Спасибо сказали: 0 раз(а)




Репутация:   0  


Как считаете, господа?

Есть у меня GUI, созданный при помощи QML. Есть "движок" программы. Есть, соответственно, задача реализации обмена данными между ними.

Сначала я сделал таким образом, что множество сигналов от интерфейса связывались непосредственно с конкретными функциями движка, ну и в обратную сторону аналогично. Теперь решил переделать это так, что бы было всего 2-3 сигнала в каждую сторону, но теперь каждый сигнал будет нести в себе информацию о том, от кого он, какую операцию представляет, ну и данные. И есть столько же функций приемников, которые занимаются распределением пришедших данных уже по конкретным функциям. Такая вот прослойка. В итоге получаем уменьшение количества, скажем так, каналов связи между GUI и движком, и, возможно, некоторую универсальность, на будущее, при добавлении новых функций с той или другой стороны.

Пишу это, потому что имеются некоторые сомнения в сердце :rolleyes: , насколько оправдан такой подход?

Как считаете, господа?)
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
RazrFalcon
  опции профиля:
сообщение 23.3.2012, 14:14
Сообщение #2


Zombie Mod
*****

Группа: Участник
Сообщений: 1654
Регистрация: 24.5.2010
Из: Харьков
Пользователь №: 1752

Спасибо сказали: 64 раз(а)




Репутация:   212  


Если сигналов очень много можно заюзать QSignalMapper и подобные.

А так - предпочтение каждого. Я вот не люблю в сигнале передавать 100500 параметров. Разве что их в структуру/класс загнать, и уже это передавать.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
call_me_Frank
  опции профиля:
сообщение 23.3.2012, 16:03
Сообщение #3


Студент
*

Группа: Участник
Сообщений: 73
Регистрация: 20.10.2010
Пользователь №: 2129

Спасибо сказали: 0 раз(а)




Репутация:   0  


Цитата(RazrFalcon @ 23.3.2012, 14:14) *
Если сигналов очень много можно заюзать QSignalMapper и подобные.

А так - предпочтение каждого. Я вот не люблю в сигнале передавать 100500 параметров. Разве что их в структуру/класс загнать, и уже это передавать.


отлично, спасибо! щас почитаю ;)

нет, всё-таки, QSignalMapper - это не тот вариант...

вот что еще хотел узнать (пока с этим сталкиваться не приходилось, в поиске с ходу тоже не нашел), можно ли каким-то образом вызывать метод объекта по его "текстовому" названию, то есть вызывать не как obj.method1(params), а как-нибудь вроде obj.methods["method1"](params); ?
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
MoPDoBoPoT
  опции профиля:
сообщение 23.3.2012, 23:08
Сообщение #4


Участник
**

Группа: Участник
Сообщений: 172
Регистрация: 7.5.2009
Из: Москва
Пользователь №: 738

Спасибо сказали: 44 раз(а)




Репутация:   9  


Цитата(call_me_Frank @ 23.3.2012, 17:03) *
можно ли каким-то образом вызывать метод объекта по его "текстовому" названию, то есть вызывать не как obj.method1(params), а как-нибудь вроде obj.methods["method1"](params); ?

QMetaObject::invokeMethod()
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Гость_Гость_*
сообщение 26.3.2012, 20:05
Сообщение #5





Гости








    


Можно, например, в QML код передавать некий высокоуровневый обьект(ы), который представляет на нужном уровне детализации весь серверный код и производить общение уже через него . На проекте на котором я работаю именно такая архитектура и используется, и вполне успешно.
Например если пишешь некий плеер, то в первом приближении это выглядело бы примерно так:
class IPlayer: public QObject
{
   Q_OBJECT
public:
virtual void loadServer() =0;
virtual void openFile(const QString & fileName) = 0;
virtual void play() = 0;
signals:
void serverLoaded(ServerError error);
void fileOpened(FileError error);
void playbackBegin();
void playBackErrorOccured(PlayBackError);
void playbackEnd();
};

Притом обьект может быть один а интерфейсов сколько угодно, правда тогда скорей всего придется отказаться от плюшек QObject'a или делать какую нибудь унифицированною систему эвентов построеную на сигналах. Хотя Qt'ишная система плагинов вроде позволяет такой подход без отказа от QObject, попробуй почитать про всякие Q_DECLARE_INTERFACE, Q_INVOKABLE и т.д.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение

Быстрый ответОтветить в данную темуНачать новую тему
Теги
Нет тегов для показа


1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0




RSS Текстовая версия Сейчас: 30.6.2022, 22:50