Здравствуйте, LaptevVV, Вы писали:
LVV>... LVV>Ибо если Qt — то студенты начинаю лепить прогу сразу в дизайнере. LVV>И лепят бизнес-код в классы интерфейса. LVV>Нужно заставить их отделять реализацию бизнес-логики от реализации интерфейса. LVV>Что скажете?
Запретите им пользоваться виджетами, пусть делают весь GUI на QML (QtQuick). Очень простой синтаксис, и хочешь не хочешь — придётся разделять логику. Вот из этой темы
Здравствуйте, LaptevVV, Вы писали:
LVV>Нужно заставить их отделять реализацию бизнес-логики от реализации интерфейса.
Зачем? Какая задача — такая и архитектура. Если мне надо посчитать 2+2, то городить из-за этого какие-то слои глупо. Надо им ставить такие задачи, где лапша из бизнес-логики и UI тупо неудобна.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, LaptevVV, Вы писали:
... LVV>А задлача моя простая. LVV>ЗАСТАВИТЬ студентов отделять мух от котлет. LVV>Ибо если все делается на С++, то ОЧЕНЬ немногие на 2 курсе понимают, LVV>что интерфейс и бизнес-логика (какая бы она ни была) — это две БОЛЬШИЕ разницы. LVV>При программировании в Qt многократно наблюдал реализацию ВСЕГО в классе mainwindow. LVV>Устаешь постоянно с этим бороться.
Бороться — не надо!
А поставить задачу по типу:
Сделать единый набор классов (обозначим его как Core), реализующий определенную, заранее оговоренную, бизнес-логику.
Данный набор Core мы применим далее в виде двух приложений и теста:
1) Приложение с GUI (используй тот же Qt, STL, если надо — boost);
2) Приложение командной строки (используй STL, и при необходимости boost);
3) Дополнительно — сделать Unit-тест для проверки функционирования вышеупомянутого набора Core классов.
Для первого случая — сделаем "адаптер" (обозначим его как GUIProxy) — являющийся мостиком между GUI и бизнес логикой.
Для второго случая — сделеам простейшую обертку — для парсинга параметров командной строки.
А третий — обеспечить набор проверочных данных и запустить Unit-test.
Лично я, здесь бы применил boost — так как Qt уже применялось в процессе создания GUI версии приложения.
LVV>Хочется, чтобы инструментарий просто не позволял такого подхода.
Инструментарий может позволять многое. И должен позволять многое
Постановка ТЗ — должна поставить требуемые рамки.
P.S. Если есть желание сделать задачу ещё разнообразней и интересней —
можно предложить сделать кроссплатформенную реализацию: Linux (Ubuntu; Debian) и Windows
Мне кажется, частично проблему удалось решить.
В этом годе на 2 курсе нашлось 2 пацана, которые получили курсовую по модификации FLTK.
Это библиотека, которую использует Страуструп в своих книжках для студентов.
У нас они называются "Два гуся" и "Три гуся".
Библиотека относительно простая, но имела проблему с руссификацией в Windows.
Пацаны нашли проблемное место и решили проблему.
Взяли исходный fooltik и в качестве курсовой написали набор руссифицированных виджетов.
Писали в CLion — сразу для Linux и для Windows
Еще один пацан взял у них некоторую версию и слабал на ней оконный интерфейс к своей курсовой...
В чем прелесть — нет дизайнера и весь GUI надо писать ручками!
Единственная пока проблема — пока не написали даже краткий док по использованию.
Но за лето обещались сделать.
Кому надо — в сентябре постараюсь покласть сюда в приемлемом виде с доком...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Помнится, у нас был отдельный курс по разработке интерфейсоов.
Там элементы этого давались.
Есть ли сейчас — не в курсе. Давно в учебный план не лазил.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>А про это кто чего скажет?
Смотря для чего.
Vue и отец ея Angular это декларативный маппинг/биндинг DOM дерева на некую структуру данных (JSON).
Т.е. это можно изучать как пример предельной (ultimate) изоляции данных (model) от представления (view). ( В Sciter кстати есть аналогичный фреймворк — samples/+plus )
Понять особенности построения UI из этих фреймворков — сложно.
На самом деле я бы серьезно рекомендовал Sciter — там есть как native API к DOM и событиям так и параллельный механизм в скрипте.
Т.е. можно использовать как в курсе C++ так и в чем-то другом.
Освоив Sciter UI (HTML/CSS/DOM/script/native) можно заниматься как web frontend UI так и native UI.
Здравствуйте, LaptevVV, Вы писали:
LVV>Почитал про Sciter... LVV>Если кто работал — поделитесь впечатлениями LVV>Хочу использовать в курсовых для реализации интерфейса. LVV>Ибо если Qt — то студенты начинаю лепить прогу сразу в дизайнере. LVV>И лепят бизнес-код в классы интерфейса.
LVV>Нужно заставить их отделять реализацию бизнес-логики от реализации интерфейса. LVV>Что скажете?
Пусть пишут на QML, лучше вообще поставить задачу чтобы был отедльный проект(lib,dll) без использования Qt, только C++ и boost, и интерфейс на QML, им тогда придется написать +1 плагин обертку чтобы прокинуть данные из QML в C++ и обратно(даже если совместят с основным интерфейсом не страшно, логическое отделение будет), и как плюс новые знания по декларативному написанию программ.
Или запретить использовать QTableWidget,QTreeWidget, пусть через QTableView,QTreeView делают, там модель будет, или задачи ставить такие, где если не использовать модель, то нужно очень много делать, Frozen Column например, или похожее чтобы в разных view отображались одновременно данные из одной модели.
Здравствуйте, LaptevVV, Вы писали:
N>>Правильное решение тебе уже сказали — заставь их делать CLI в дополнение к гуйне. LVV>Стесняюсь просить: CLI — это что? https://en.wikipedia.org/wiki/Command-line_interface
Здравствуйте, LaptevVV, Вы писали:
LVV>Почитал про Sciter... LVV>И лепят бизнес-код в классы интерфейса.
Вещь хорошая, но требует знания html и скупо документированная.
LVV>Нужно заставить их отделять реализацию бизнес-логики от реализации интерфейса. LVV>Что скажете?
К решению задачи отделения логики от реализации ортогонально.
Здравствуйте, LaptevVV, Вы писали:
LVV>А про это кто чего скажет?
Есть миллион реактивных js-фрэймворков, но для их освоение требуется знание кучи всякой требухи, которая ни к архитектуре, ни к плюсам отношения не имеет. Зачем забивать себе и студням этим голову?
Правильное решение тебе уже сказали — заставь их делать CLI в дополнение к гуйне.
Здравствуйте, LaptevVV, Вы писали:
LVV>Нужно заставить их отделять реализацию бизнес-логики от реализации интерфейса. LVV>Что скажете?
Заставить их писать кроссплатформенные велосипеды.
То есть никаких Qt, но пусть пишут ядро бизнес-логики, которое компилируется хотя бы на msvc и gcc, и пара-тройка простеньких реализаций интерфейса — скажем на winapi, xwindow и cocoa. Пусть все будет простенькое, но обязательное требование — общий код ядра и как можно меньший объем кода в интерфейсах.
Или например можно требовать чтобы код ядра был общий, а варианты интерфейса — оконный (GUI), консольный (TUI) и web-морда.
Нет такого преступления, на которое не пошло бы суверенное родоплеменное быдло ради продления своего бессмысленного рода и распространения своего бессмысленного генома.
Почитал про Sciter...
Если кто работал — поделитесь впечатлениями
Хочу использовать в курсовых для реализации интерфейса.
Ибо если Qt — то студенты начинаю лепить прогу сразу в дизайнере.
И лепят бизнес-код в классы интерфейса.
Нужно заставить их отделять реализацию бизнес-логики от реализации интерфейса.
Что скажете?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Нужно заставить их отделять реализацию бизнес-логики от реализации интерфейса. LVV>Что скажете?
Пусть реализуют попутно какой-то REST API и возможность стартовать как сервис, допустим. Это их вынудит выделить "движок" с бизнес-логикой, который можно стартовать как headless-сервис. А сам UI, например, уже есть заранее готовый (главное его сконфигурить на нужный порт локал-хоста).
Здравствуйте, LaptevVV, Вы писали:
LVV>Нужно заставить их отделять реализацию бизнес-логики от реализации интерфейса. LVV>Что скажете?
На самом деле полезно даже не в смысле архитектуры, а в том что HTML/CSS для UI practitioners нужно знать по любому.
Ну и понятие что UI code flow сильно отличается от линейного кода бизнес-логики.
Ничего конкретного так и не сказали.
А задлача моя простая.
ЗАСТАВИТЬ студентов отделять мух от котлет.
Ибо если все делается на С++, то ОЧЕНЬ немногие на 2 курсе понимают,
что интерфейс и бизнес-логика (какая бы она ни была) — это две БОЛЬШИЕ разницы.
При программировании в Qt многократно наблюдал реализацию ВСЕГО в классе mainwindow.
Устаешь постоянно с этим бороться.
Хочется, чтобы инструментарий просто не позволял такого подхода.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, c-smile, Вы писали:
... CS>Но если говорить про UI если не от сохи а от трактора, то надо смотреть MFC / wxWidgets или тот же QT. CS>Они все имплементируют изначальный IBM CUA : https://www.amazon.com/Object-Oriented-Interface-Design-Common-Guidelines/dp/1565291700
+100500
Только несколько примечаний:
MFC — достаточно старый фреймворк, не думаю что актуален для студентов в 2018
wxWidgets — специфическая штука (на любителя), также актуальность под вопросом
Qt — IMHO самое то, что надо!
