Переодически приходят заказы на разработку настольных приложений, и каждый раз я смотрю на разработку UI как баран на новые ворота. В основном из-за непонимания как эффективно разделять модель и представление. Какие хорошие книги или серии статей есть на эту тему?
C>Переодически приходят заказы на разработку настольных приложений, и каждый раз я смотрю на разработку UI как баран на новые ворота. В основном из-за непонимания как эффективно разделять модель и представление. Какие хорошие книги или серии статей есть на эту тему?
UI разрабатывается на основе функция, которые пользователь делает в системе.
Поэтому рекомендую прочитать книгу Алистера Коберна: https://www.labirint.ru/books/421003/
Сильно прояснится.
Книжка небольшая, но очень информативная.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, cppguard, Вы писали:
C>Переодически приходят заказы на разработку настольных приложений, и каждый раз я смотрю на разработку UI как баран на новые ворота. В основном из-за непонимания как эффективно разделять модель и представление. Какие хорошие книги или серии статей есть на эту тему?
Это же зависит от того на чем вы пишете UI. Вообще есть два самых распространенных паттерна MVC и MVVM. А так я бы смотрел документацию и примеры по либе с помощью которой ведется разработка.
Здравствуйте, BlackEric, Вы писали:
BE>Это же зависит от того на чем вы пишете UI.
А если в задачу входит и выбор средств реализации UI тоже?
BE>Вообще есть два самых распространенных паттерна MVC и MVVM. А так я бы смотрел документацию и примеры по либе с помощью которой ведется разработка.
Подозреваю, что вопрос ТС был понят не до конца. У меня вот тоже всегда была такая же (в плане выбора визуальных средств для представления модели) проблема с UI. Например, модель включает несколько параметров, которые могут быть включены/выключены. Обычно такое делается чекбоксами или двумя списками (все и выбранные). Когда параметров два-три, и нагляднее, и удобнее сделать чекбоксы. Когда пятьдесят — списки. А когда их восемь, десять, двенадцать? Надо ж еще как-то учесть предпочтения пользователей, а они могут быть сильно разными.
Здравствуйте, LaptevVV, Вы писали:
LVV>прочитать книгу Алистера Коберна LVV>Сильно прояснится.
Пролистал ее по диагонали — по-моему, она переусложнена. То, что там подробно расписывается и разжевывается, чаще всего само становится понятным после определения задач и способов взаимодействия. А способы взаимодействия — это уже больше изобретательство.
Например, в метро разных стран еще много лет назад можно было купить жетоны или разовые билеты, заплатив картой, и совершенствовалась именно такая система оплаты. Лишь недавно появились турникеты, к которым можно приложить карту непосредственно. Казалось бы, элементарно — но ведь не допер никто раньше.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Подозреваю, что вопрос ТС был понят не до конца. У меня вот тоже всегда была такая же (в плане выбора визуальных средств для представления модели) проблема с UI. Например, модель включает несколько параметров, которые могут быть включены/выключены. Обычно такое делается чекбоксами или двумя списками (все и выбранные). Когда параметров два-три, и нагляднее, и удобнее сделать чекбоксы. Когда пятьдесят — списки. А когда их восемь, десять, двенадцать? Надо ж еще как-то учесть предпочтения пользователей, а они могут быть сильно разными.
Как например, помещаются на экране — чекбоксы, не помещаются — списки.
Чётное количество — радость перфекциониста.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Например, в метро разных стран еще много лет назад можно было купить жетоны или разовые билеты, заплатив картой, и совершенствовалась именно такая система оплаты. Лишь недавно появились турникеты, к которым можно приложить карту непосредственно. Казалось бы, элементарно — но ведь не допер никто раньше.
Метро транспорт бедных.
Карта перестала быть роскошью.
Утрата карты (украли-отжали) и утрата жетона. Есть разница.
Здравствуйте, akasoft, Вы писали:
A>Как например, помещаются на экране — чекбоксы, не помещаются — списки.
На каком экране? Они бывают и 1024x600 (до сих пор), и 12K. Кому-то нравится большое количество чекбоксов в развесистом диалоге, поскольку все сразу видно и под рукой, а кому-то подавай диалог покомпактнее, и тогда — только списки. Как понять заранее, каких больше?
Здравствуйте, cppguard, Вы писали:
C>Переодически приходят заказы на разработку настольных приложений, и каждый раз я смотрю на разработку UI как баран на новые ворота. В основном из-за непонимания как эффективно разделять модель и представление. Какие хорошие книги или серии статей есть на эту тему?
Ставишь Lazarus и пишешь всю бизнес-логику как реакцию на события кнопок и прочих элементов интерфейса, "модель" хранишь как часть полей форм, т.е. "вида". Заморачиваться MVC и прочим имеет смысл только для сложных приложений.
Здравствуйте, akasoft, Вы писали:
A>Метро транспорт бедных.
Вы там давно были? Посмотрите, кто там ездит в часы пик — удивитесь. И не только в московском, и не только в России.
A>Карта перестала быть роскошью. A>Утрата карты (украли-отжали) и утрата жетона. Есть разница.
Не вижу разницы. Зачем к автоматам, продающим жетоны/билеты, картоприемники приделали еще лет двадцать назад, а к турникетам — совсем недавно? Бесконтактные карты тут ни при чем — списывать мелкие суммы без PIN-кода можно было и тогда.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Подозреваю, что вопрос ТС был понят не до конца. У меня вот тоже всегда была такая же (в плане выбора визуальных средств для представления модели) проблема с UI. Например, модель включает несколько параметров, которые могут быть включены/выключены. Обычно такое делается чекбоксами или двумя списками (все и выбранные). Когда параметров два-три, и нагляднее, и удобнее сделать чекбоксы. Когда пятьдесят — списки. А когда их восемь, десять, двенадцать? Надо ж еще как-то учесть предпочтения пользователей, а они могут быть сильно разными.
Всё верно. Проблема не закодить сам UI, а выполнить взаимодействие пользовательского интерфейса с моделью так, чтобы потом не было больно расширять приложение. Последение пару раз я отказывался от UI вообще и программировал DSL, благо, что заказчики радостно соглашались.
Здравствуйте, gyraboo, Вы писали:
G>Здравствуйте, cppguard, Вы писали:
C>>Переодически приходят заказы на разработку настольных приложений, и каждый раз я смотрю на разработку UI как баран на новые ворота. В основном из-за непонимания как эффективно разделять модель и представление. Какие хорошие книги или серии статей есть на эту тему?
G>Ставишь Lazarus и пишешь всю бизнес-логику как реакцию на события кнопок и прочих элементов интерфейса, "модель" хранишь как часть полей форм, т.е. "вида". Заморачиваться MVC и прочим имеет смысл только для сложных приложений.
И это предлагает человек, который ставит процессы разработки в различных конторах?
Здравствуйте, BlackEric, Вы писали:
C>>>Переодически приходят заказы на разработку настольных приложений, и каждый раз я смотрю на разработку UI как баран на новые ворота. В основном из-за непонимания как эффективно разделять модель и представление. Какие хорошие книги или серии статей есть на эту тему?
G>>Ставишь Lazarus и пишешь всю бизнес-логику как реакцию на события кнопок и прочих элементов интерфейса, "модель" хранишь как часть полей форм, т.е. "вида". Заморачиваться MVC и прочим имеет смысл только для сложных приложений.
BE>И это предлагает человек, который ставит процессы разработки в различных конторах?
Ну да, если разрабатывать "по уму по MVC", то дороже выйдет. MVC весьма усложняет разработку и сам код, и требует от людей определенной квалификации, которую не всегда найдешь среди суппортеров. А простецкий "дельфийский" подход к клепанию GUI весьма дешев и эффективен, он начинает давать сбой только для сложных ГУИ-шных проектов.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>На каком экране?
На том, на котором будут показаны. ЕМ> Кому-то нравится большое количество чекбоксов в развесистом диалоге, поскольку все сразу видно и под рукой, а кому-то подавай диалог покомпактнее, и тогда — только списки.
Восприятие разнится от человека к человеку. Всем не угодить. ЕМ>Как понять заранее, каких больше?
Спросить. Или предположить.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вы там давно были? Посмотрите, кто там ездит в часы пик — удивитесь. И не только в московском, и не только в России.
Вот поэтому карта и перестала быть роскошью. Мультипаспорт.
ЕМ>Не вижу разницы.
Раньше была разница, украли у тебя карту или жетон на метро. Карта была роскошью.
ЕМ> Зачем к автоматам, продающим жетоны/билеты, картоприемники приделали еще лет двадцать назад, а к турникетам — совсем недавно?
Не позволяли доступные технологии и консерватизм владельцев бизнеса. "Работает — не трогай" во всей красе.
Здравствуйте, akasoft, Вы писали:
A>Раньше была разница, украли у тебя карту или жетон на метро.
В чем была разница? Я вижу разницу только в сроках выпуска новой карты (пара недель двадцать лет назад, один-два — сейчас).
A>Карта была роскошью.
В 90-х карта была роскошью только в развивающихся странах (в России тоже). Уже в самом начале 2000-х карты выпускали десятки банков, они были доступны всем желающим, тогда же начали перечислять туда зарплаты. Другое дело, что в России до середины 2000-х было особо некуда совать те карты, кроме банкоматов, но в США и Западной Европе торговых точек, принимавших карты, было до хренища и в 90-е.
A>Не позволяли доступные технологии и консерватизм владельцев бизнеса. "Работает — не трогай" во всей красе.
Технологии как раз были доступны — просто никто не думал, что это может иметь значительный спрос.
Здравствуйте, cppguard, Вы писали:
C>Переодически приходят заказы на разработку настольных приложений, и каждый раз я смотрю на разработку UI как баран на новые ворота. В основном из-за непонимания как эффективно разделять модель и представление. Какие хорошие книги или серии статей есть на эту тему?
Начни с About Face https://www.amazon.com/About-Face-Essentials-Interaction-Design/dp/1118766571
Иначе начнешь делать с модели и получишь не самый лучший интерфейс.
Здравствуйте, cppguard, Вы писали:
C>Переодически приходят заказы на разработку настольных приложений, и каждый раз я смотрю на разработку UI как баран на новые ворота. В основном из-за непонимания как эффективно разделять модель и представление. Какие хорошие книги или серии статей есть на эту тему?
Создай класс-фасад с методами-бизнес логики: добавить то-то, удалить то-то, посчитать то-то. В общем, то, что делает твое приложение.
Методы этого класса — это контракт между моделью и представлением. Для выполнения любых операций представление должно работает только с этим классом и ни с чем больше.
Представление может быть реализовано как угодно — создавай любые классы — для окон, для настроек, и т.п.
Реализация бизнес-логики тоже как угодно — создавай классы для алгоритмов, бизнес-объектов, файлов, внешних сервисов и т.п.
Если возникают сомнения, является ли что-то бизнес-логикой (должно быть в модели) или логикой представления (должно быть в представлении), то представь сразу что ты в дальнейшем разработаешь другие интерфейсы, кроме графического будет текстовый, голосовой и т.п. Если поведение одинаковое для всех видов интерфейсов — это бизнес-логика, если отличается — это представление.
Здравствуйте, Буравчик, Вы писали:
C>>Переодически приходят заказы на разработку настольных приложений, и каждый раз я смотрю на разработку UI как баран на новые ворота. В основном из-за непонимания как эффективно разделять модель и представление. Какие хорошие книги или серии статей есть на эту тему?
Б>Создай класс-фасад с методами-бизнес логики: добавить то-то, удалить то-то, посчитать то-то. В общем, то, что делает твое приложение.
Б>Методы этого класса — это контракт между моделью и представлением. Для выполнения любых операций представление должно работает только с этим классом и ни с чем больше.
Б>Представление может быть реализовано как угодно — создавай любые классы — для окон, для настроек, и т.п. Б>Реализация бизнес-логики тоже как угодно — создавай классы для алгоритмов, бизнес-объектов, файлов, внешних сервисов и т.п.
Б>Если возникают сомнения, является ли что-то бизнес-логикой (должно быть в модели) или логикой представления (должно быть в представлении), то представь сразу что ты в дальнейшем разработаешь другие интерфейсы, кроме графического будет текстовый, голосовой и т.п. Если поведение одинаковое для всех видов интерфейсов — это бизнес-логика, если отличается — это представление.
Спасибо, но это прям какие-то основы промышленного проектирования. Когда взаимосвязи видно невооружённым глазом, то и проблем-то нет, а вот когда начинаются всякие циклические зависимости или неизбежно протекающие абстракции, то становится грустно.
Посмотрите, кто там ездит в часы пик — удивитесь. И не только в московском, и не только в России.
