Разделение логики и GUI

[Igors]

Код:

   connect(appender, SIGNAL(message), logwindow, SLOT(addMessage), Qt::QueuedConnection);
}

algorythm()
{
   qDebug() << error;
}

Если это ответ на мой вопрос, то как быть с "чисто UI" параметрами (иконка QMessageBox::Warning, и заголовок окна "Error")? Далеко не всегда UI есть "просто лог вставленный в окошко". Как поможет лихое перенаправление qDebug() если потребуется спросить Yes/No/Cancel?

[asvil]

Для интерактивности необходим дополнительный код. Могу дополнить вышеприведенный листинг. Только моя реализация приблизит архитектуру к разделению на консольную версию программы и гуи фронт-енда.

[Igors]

другой вариант - возвращать из функции QString, а не bool (в случае успеха - QString(), неудачи - сообщение с ошибкой), но тогда не получится красивого

По-моему более естественно так

Код

C++ (Qt)
if (value > limit)    // обнаружили 
// сохраняем текст ошибки (который потом можно получить GetLastError и возвращаем false)
 return theErrorMgr::SetLastError("overflow");  
 

А theErrorMgr находится в др файле и умеет работать с UI и без. В принципе если просто "текст ошибки" то проблем нет, и, на мой взгляд, задействовать qDebug() ни к чему. Но в том-то и дело что UI всегда имеет "мелкие подробности" которые специфичны и в общую схему упорно не укладываются  (напр титул окна, иконка(и), какой-то (дополнительный) хелп текст, что-то надо выравнять направо и.т.п)

Могу дополнить вышеприведенный листинг. Только моя реализация приблизит архитектуру к разделению на консольную версию программы и гуи фронт-енда.

Ну если нетрудно, покажите (или расскажите в чем там смысл)

[lit-uriy]

>>Как мы видим UI проникло/просочилось в cpp файл который занят разбором текста
>>(т.е. никакого отношения к UI иметь не должен). Как этого избежать?
Я уже давно не использую "ничейных" функций, только классы.
И использую, при необходимости, строковые переменные типа "последняя ошибка", метод класса возвращает ЛОЖЬ, при этом в вызывающем коде зовётся метод типа "Дай последнюю ошибку". Ну а дальше, зависит от того, является ли вызывающий код человеко-машинным интерфейсом (консольным или графическим, не важно) или нет.

[Igors]

Я уже давно не использую "ничейных" функций, только классы.
И использую, при необходимости, строковые переменные типа "последняя ошибка", метод класса возвращает ЛОЖЬ, при этом в вызывающем коде зовётся метод типа "Дай последнюю ошибку".

То ясно (см. мой предыдущий пост), толкуем о том что "текст ошибки" хорош для консоли, но (как правило) это еще не все что нужно UI

[asvil]

или расскажите в чем там смысл

Смысл в том чтобы код ui и код алгоритма обменивались сообщениями в блокирующих/неблокирующих режимах в зависимости от потребностей. Код алгоритма вызывает write("Continue?"); if read() == n {stop}. Код ui показывает сообщение ну и, если оно требует ответа, ждет ответ. Ответ отправляется коду алгоритма.

[Авварон]

делать классы реентрантными, возвращать ф-ией бул и иметь ф-ию lastError()
для асинхронных классов - сигнал эррор()

[Igors]

или расскажите в чем там смысл

Смысл в том чтобы код ui и код алгоритма обменивались сообщениями в блокирующих/неблокирующих режимах в зависимости от потребностей. Код алгоритма вызывает write("Continue?"); if read() == n {stop}. Код ui показывает сообщение ну и, если оно требует ответа, ждет ответ. Ответ отправляется коду алгоритма.

Слот/сигнал никакой не magic и "зависимостей" не развязывает. Да, с его помощью легко избавиться от UI "в явном виде", т.е. файл не требует <QtGui>, но от этого не станет легче. Как Вы сообщите вызывающему оте "мелкие подробности" (которые Вы стараетесь не замечать - поправьте если не так). Ведь даже в простейшем случае нужен заголовок окна и тип иконки. Начнете плодить больше слотов/сигналов? Так Вы скоро устанете и, когда сроки прижмут, начнете лепить UI напрямую

делать классы реентрантными, возвращать ф-ией бул и иметь ф-ию lastError()
для асинхронных классов - сигнал эррор()

- почему ты ищешь только под фонарем?
- да потому что только там светло!

[lit-uriy]

Можно завести вспомогательный класс описывающий ошибку, удобный и для графического интерфейса и для текстового.

[lit-uriy]

>>нужен заголовок окна и тип иконки
заголовок, если это не имя приложения, то тип сообщения (ошибка, предупреждение, ...). А тип сообщения однозначно связан с картинкой.
Из логики программы за ранее известно, что если сейчас функция вернёт ЛОЖЬ, то - ошибка (предупреждение,...).

[asvil]

Как Вы сообщите вызывающему оте "мелкие подробности"

Енто называется протокол общения, в моем примере текстовый. Употреблять бинарный по желанию.

lit-uriy класс то можно, вопрос в том как оптимальнее наследить в коде, что бы реализовать разделение мух и котлет, и чтобы и те и другие друг про друга знали.

[Igors]

>>нужен заголовок окна и тип иконки
заголовок, если это не имя приложения, то тип сообщения (ошибка, предупреждение, ...). А тип сообщения однозначно связан с картинкой.
Из логики программы за ранее известно, что если сейчас функция вернёт ЛОЖЬ, то - ошибка (предупреждение,...).

Ну допустим, чуть сэкономили - вместо 2 параметров 1, но это так, "на спичках" - проблема-то остается. UI будет порождать десятки подобных параметров,  отделаться просто "текстом ошибки" (a la Linux) никак не удастся

Можно завести вспомогательный класс описывающий ошибку, удобный и для графического интерфейса и для текстового.

Этот класс быстро превращается в "помойную яму" (типа Вындоуз реестра) в которую каждый конкретный интерфейс льет свое. В одном UI потребуется одно, в другом UI - другое.  Получается что вызывающий должен знать все подробности всех интерфейсов - расписываемся в беспомощности.

Как Вы сообщите вызывающему оте "мелкие подробности"

Енто называется протокол общения, в моем примере текстовый. Употреблять бинарный по желанию.

lit-uriy класс то можно, вопрос в том как оптимальнее наследить в коде, что бы реализовать разделение мух и котлет, и чтобы и те и другие друг про друга знали.

Рад что Михаил на Линуксе меня понимает (а не просто изрекает прописные истины )  Давайте исполним протокол, пусть он будет не perfect, это нормально. А то отделаться "текстом ошибки" всем ясно. Ваши предложения?

[Lagovas]

Много ли типов ошибок? Сделать какой нить доступный enum, и передавать как параметр. А вообще, разве при написании гуя, не ясно какие там могут быть ошибки? Заглавие делать обобщенным, типа Ошибка в работе с файлом, а в тексте уже подробности, которые предоставляет логика.

[Igors]

Много ли типов ошибок? Сделать какой нить доступный enum, и передавать как параметр. А вообще, разве при написании гуя, не ясно какие там могут быть ошибки? Заглавие делать обобщенным, типа Ошибка в работе с файлом, а в тексте уже подробности, которые предоставляет логика.

Конечно "типов ошибок" совсем немного - но передавать этот параметр надо. Но наивно думать что отделаемся "текстом ошибки" + "типом ошибки" - это мы просто "воспроизвели ситуацию на следующем шаге". Очень быстро появляются "исключения" которые требуют 3-й параметр (следующий шаг). Когда число таких "шагов" переваливает за 8-10, думается типа "ну надо же что-то делать, как-то обобщать"

[kambala]

можно попробовать паковать все в словарь, список, или строку с особыми разделителями