Вопрос архитектуры приложения Опции

[call_me_Frank]

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

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

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

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

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

[RazrFalcon]

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

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

[call_me_Frank]

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

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

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

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

вот что еще хотел узнать (пока с этим сталкиваться не приходилось, в поиске с ходу тоже не нашел), можно ли каким-то образом вызывать метод объекта по его "текстовому" названию, то есть вызывать не как obj.method1(params), а как-нибудь вроде obj.methods["method1"](params); ?

[MoPDoBoPoT]

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

QMetaObject::invokeMethod()

[Гость_Гость_*]

Можно, например, в 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 и т.д.