Как считаете, господа?
Есть у меня GUI, созданный при помощи QML. Есть "движок" программы. Есть, соответственно, задача реализации обмена данными между ними.
Сначала я сделал таким образом, что множество сигналов от интерфейса связывались непосредственно с конкретными функциями движка, ну и в обратную сторону аналогично. Теперь решил переделать это так, что бы было всего 2-3 сигнала в каждую сторону, но теперь каждый сигнал будет нести в себе информацию о том, от кого он, какую операцию представляет, ну и данные. И есть столько же функций приемников, которые занимаются распределением пришедших данных уже по конкретным функциям. Такая вот прослойка. В итоге получаем уменьшение количества, скажем так, каналов связи между GUI и движком, и, возможно, некоторую универсальность, на будущее, при добавлении новых функций с той или другой стороны.
Пишу это, потому что имеются некоторые сомнения в сердце , насколько оправдан такой подход?
Как считаете, господа?)
Если сигналов очень много можно заюзать QSignalMapper и подобные.
А так - предпочтение каждого. Я вот не люблю в сигнале передавать 100500 параметров. Разве что их в структуру/класс загнать, и уже это передавать.
Можно, например, в 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();
};
Форум Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)