Z>>А если нету таймера? Если все выполняется в одном потоке?
V>Есть системное время, вычисляй разность с последней операции и если оно больше заданной дельты обновляй интерфейс взаимодействия с пользователем.
V>Вопрос здесь скорее во сколько тебе обходится показ прогресса и стоит ли выводить его весь с каждой операции или только часть с задержкой по дельте времени, например, 0.1 сек, чтобы показать, что он есть.
Все правильно.
Какой код (какой слой\модуль\метод) дожен выполнять эту работу? И откуда будет вызываться этот код?
То есть у меня вопрос скорее про разделение отвественности, а не про "техническую" начинку.
V>И в принципе я написал по этому поводу.
V>Почему программисты прошлого были умнее
Да, я читал эту статью. И горячие обсуждения этой статьи.
V>Это типичная ловушка абстракций. GUI это самый обычный условно бесконечный цикл пока не будет выполнено условие выхода. И внутри него крутятся циклы обработки сообщений или называй как хочешь.
V>Фактически это машина состояний как в том же контроллере. То есть вся эта байда будет работать даже если программист не продвинулся дальше процедурного программирования с блоком, ветвлением и циклом.
V>Плюс получение системного времени или чего-то похожего учитывающего перевод часов. В общем смысл в простеньких алгоритмах уровня программистов аппаратчиков, см. статью выше.
V>А вот на третьем уровне абстракционистов нет понимания работы компьютера. На нём работают уже состоявшиеся в алгоритмах программисты, которые просто записывают их иначе.
V>Это как раз все эти шаблоны проектирования и прочее. Например, шаблон проектирования итератор внутри является самым обычным циклом относящимся к синтаксису языка программирования.
V>Все эти шаблоны это здорово и хорошо, но они не дают понимания алгоритмов, причём даже самых простых, а часто напротив превращают нечто сверх простое в сверх сложное.
В общем согласен. Знание и понимание "азов" помогает в более высокоуровневом программировании.
Я начинал писать на ассемблере, потом на С, потом на С++ и так далее.
Кстати и эту программу я пишу на процедурном языке, в котором нету классов.
Но это не исключает применение принципов разделения кода, которые были наработаны "потом и кровью".
Эти принципы были наработаны в том числе и программистами прошлого, которые дали нам (современным программистам) огромный опыт, в том числе и такой опыт как не надо делать.
Ведь, например, насколько я помню MVC был придуман когда еще не было ни ООП ни шаблонов проектирования.
V>В общем сначала нужно учить алгоритмы и структуры данных, пусть даже это будет процедурное программирование, и лишь потом переводить работающий алгоритм в некую абстракцию по сути делающую тоже самое.
Алгоритм тут как раз простой: изменили данные — перерисуй интерфейс. Структуры данных тоже понятные и простые.
Тут вопрос больше относится к тому, как организовать\разделить код так, чтобы программа оставалась поддерживаемой\расширяемой и т.д.
Чистая Архитектура — мне кажется именно про это.
Автор предлагает разделить этот код на части (грубо говоря на отдельные методы), которые он называет определенными терминами, и которые должны вызываться в следующем порядке:
Controller -> UseCaseInteractor (InputPort) -> Presenter (OutputPort).
V>А про Мартина Роберта с его книгами Чистым Кодом, Чистым Кодером, Чистой Архитектурой и Чистым Agile, скажу так, сам он начинал с перфокарт. Статья же на хабре вторична и не имеет отношения к этому автору.
Да, я это понимаю. Книгу читаю.
Но в самой книге нету про длительные операции.
Там, например, говорится о подготовке отчета: Контроллер вызвал Интерактора, который готовит отчет. Интерактор после выполнения отдает эти данные Презентеру. Презентер управляет отображением этого отчета.
Но мне нужно, чтобы кроме отображения отчета, еще отобразить и процесс его формирования\подготовки. Об этом в книге ничего не сказано.
Вот поэтому я и советуюсь с сообществом: как это лучше сделать?
