Здравствуйте, LaptevVV, Вы писали:
...
LVV>А задлача моя простая.
LVV>ЗАСТАВИТЬ студентов отделять мух от котлет.
LVV>Ибо если все делается на С++, то ОЧЕНЬ немногие на 2 курсе понимают,
LVV>что интерфейс и бизнес-логика (какая бы она ни была) — это две БОЛЬШИЕ разницы.
LVV>При программировании в Qt многократно наблюдал реализацию ВСЕГО в классе mainwindow.
LVV>Устаешь постоянно с этим бороться.

Бороться — не надо!
А поставить задачу по типу:
Сделать один и тот же набор классов (обозначим его как Core), реализующий определенную бизнес-логику в виде двух приложений и теста:
1) Приложение с GUI (используй тот же Qt, STL, если надо — boost);
2) Приложение командной строки (используй STL, и при необходимости boost);
3) Дополнительно — сделать Unit-тест для проверки функционирования вышеупомянутого набора классов.

Для первого случая — сделаем "адаптер" (обозначим его как GUIProxy) — являющийся мостиком между GUI и бизнес логикой.
Для второго случая — сделеам простейшую обертку — для парсинга параметров командной строки.
А третий — обеспечить набор проверочных данных и запустить Unit-test.

Это можно при помощи Qt:
http://doc.qt.io/qt-5/qttestlib-tutorial1-example.html#writing-a-test

А можно (для разнообразия) — применить тот же boost:
https://www.boost.org/doc/libs/1_45_0/libs/test/doc/html/utf/tutorials.html
https://www.boost.org/doc/libs/1_45_0/libs/test/doc/html/tutorials/intro-in-testing.html

Лично я, здесь бы применил boost — так как Qt уже применялось в процессе создания GUI версии приложения.

LVV>Хочется, чтобы инструментарий просто не позволял такого подхода.

Инструментарий может позволять многое. И должен позволять многое
Постановка ТЗ — должна поставить требуемые рамки.

Здравствуйте, LaptevVV, Вы писали:
...
LVV>А задлача моя простая.
LVV>ЗАСТАВИТЬ студентов отделять мух от котлет.
LVV>Ибо если все делается на С++, то ОЧЕНЬ немногие на 2 курсе понимают,
LVV>что интерфейс и бизнес-логика (какая бы она ни была) — это две БОЛЬШИЕ разницы.
LVV>При программировании в Qt многократно наблюдал реализацию ВСЕГО в классе mainwindow.
LVV>Устаешь постоянно с этим бороться.

Бороться — не надо!
А поставить задачу по типу:
Сделать один и тот же набор классов (обозначим его как Core), реализующий определенную бизнес-логику в виде двух приложений и теста:
1) Приложение с GUI (используй тот же Qt, STL, если надо — boost);
2) Приложение командной строки (используй STL, и при необходимости boost);
3) Дополнительно — сделать Unit-тест для проверки функционирования вышеупомянутого набора классов.

Для первого случая — сделаем "адаптер" (обозначим его как GUIProxy) — являющийся мостиком между GUI и бизнес логикой.
Для второго случая — сделеам простейшую обертку — для парсинга параметров командной строки.
А третий — обеспечить набор проверочных данных и запустить Unit-test.

Это можно при помощи Qt:
http://doc.qt.io/qt-5/qttestlib-tutorial1-example.html#writing-a-test

А можно (для разнообразия) — применить тот же boost:
https://www.boost.org/doc/libs/1_45_0/libs/test/doc/html/utf/tutorials.html
https://www.boost.org/doc/libs/1_45_0/libs/test/doc/html/tutorials/intro-in-testing.html

Лично я, здесь бы применил boost — так как Qt уже применялось в процессе создания GUI версии приложения.

LVV>Хочется, чтобы инструментарий просто не позволял такого подхода.

Инструментарий может позволять многое. И должен позволять многое
Постановка ТЗ — должна поставить требуемые рамки.

P.S. Если есть желание сделать задачу ещё разнообразней и интересней —
можно предложить сделать кроссплатформенную реализацию: Linux (Ubuntu; Debian) и Windows