Сообщение Re[2]: Sciter от 12.06.2018 14:34
Изменено 12.06.2018 14:40 AlexGin
Re[2]: Sciter
Здравствуйте, LaptevVV, Вы писали:
...
LVV>А задлача моя простая.
LVV>ЗАСТАВИТЬ студентов отделять мух от котлет.
LVV>Ибо если все делается на С++, то ОЧЕНЬ немногие на 2 курсе понимают,
LVV>что интерфейс и бизнес-логика (какая бы она ни была) — это две БОЛЬШИЕ разницы.
LVV>При программировании в Qt многократно наблюдал реализацию ВСЕГО в классе mainwindow.
LVV>Устаешь постоянно с этим бороться.
Бороться — не надо!
А поставить задачу по типу:
Сделать один и тот же набор классов (обозначим его как Core), реализующий определенную бизнес-логику в виде двух приложений и теста:
1) Приложение с GUI (используй тот же Qt);
2) Приложение командной строки;
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>Хочется, чтобы инструментарий просто не позволял такого подхода.
Инструментарий может позволять многое. И должен позволять многое
Постановка ТЗ — должна поставить требуемые рамки.
...
LVV>А задлача моя простая.
LVV>ЗАСТАВИТЬ студентов отделять мух от котлет.
LVV>Ибо если все делается на С++, то ОЧЕНЬ немногие на 2 курсе понимают,
LVV>что интерфейс и бизнес-логика (какая бы она ни была) — это две БОЛЬШИЕ разницы.
LVV>При программировании в Qt многократно наблюдал реализацию ВСЕГО в классе mainwindow.
LVV>Устаешь постоянно с этим бороться.
Бороться — не надо!
А поставить задачу по типу:
Сделать один и тот же набор классов (обозначим его как Core), реализующий определенную бизнес-логику в виде двух приложений и теста:
1) Приложение с GUI (используй тот же Qt);
2) Приложение командной строки;
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>Хочется, чтобы инструментарий просто не позволял такого подхода.
Инструментарий может позволять многое. И должен позволять многое
Постановка ТЗ — должна поставить требуемые рамки.
Re[2]: Sciter
Здравствуйте, 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>Хочется, чтобы инструментарий просто не позволял такого подхода.
Инструментарий может позволять многое. И должен позволять многое
Постановка ТЗ — должна поставить требуемые рамки.
...
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>Хочется, чтобы инструментарий просто не позволял такого подхода.
Инструментарий может позволять многое. И должен позволять многое
Постановка ТЗ — должна поставить требуемые рамки.