Шаблон наблюдателя или Обратный звонок?

Question

Мне нужно создать DownloadManager, но мой главный вопрос связан с уведомлениями, которые Download может отправлять на DownloadManager, как onUpdate(), чтобы обновить индикатор выполнения, onError(),onFinish() и т. Д. Каким-то образом DownloadManager должен получать это уведомление от своих Download с.

Я думал о 2 возможных путях:

• Шаблон наблюдателя
• Обратные вызовы

Шаблон наблюдателя

В основном есть 1 наблюдаемый и N наблюдателей.В моем случае DownloadManager должен быть Наблюдателем, а Загрузки - Наблюдаемыми, так что отношение N Наблюдателей 1, как раз наоборот.

Преимущество состоит в том, чтобы централизовать все возможные уведомления в одном методе, *Метод 1025 * или update() (из java) от Observers, в моем случае только DownloadManager.Я могу передать параметр в метод notify () с кодом уведомления.

Недостаток?Я использую шаблон oop для того, что можно легко сделать с помощью обратного вызова.Кроме того, для N наблюдаемых 1 наблюдателя это что-то странное, по крайней мере с шаблоном наблюдателя, потому что этот шаблон был сделан для 1 наблюдаемого N наблюдателей, поэтому я действительно не буду использовать шаблон наблюдателя.

Обратный вызов

Очень похоже на схему наблюдателя.DownloadManager реализует «слушатель» (интерфейс).Этот прослушиватель реализует функции уведомлений onFinish (), onUpdate () и т. Д. Затем этот прослушиватель должен быть зарегистрирован во всех загрузках, поэтому, когда загрузка завершится, она вызовет listener.onFinish().Кроме того, я могу передать параметры этим методам из загрузок, как в шаблоне наблюдателя.

Преимущество: простота использования.Недостаток: нет.

Я, вероятно, буду использовать обратный вызов, потому что, по моему мнению, нет смысла использовать шаблон наблюдателя для 1 наблюдаемого N наблюдаемых.

А вы, какой вариант будете использовать?

Answer 1

Существует также одна опция, противоположная подходу Observer / Callback.Вы можете превратить клиентов DownloadManager из пассивных в активных игроков шоу.Вместо того чтобы ждать сообщения от менеджера, они будут регулярно запрашивать его статус.

Таким образом, процесс загрузки будет выглядеть намного более плавным для конечного пользователя.И вы сможете лучше контролировать его.

Конечно, вам придется использовать два потока.Или вам придется научить DownloadManager работать небольшими шагами, возвращая управление своему клиенту, вместо того, чтобы выполнять одну нерушимую часть работы.

Answer 2

наблюдатель больше подходит, потому что менеджеру необходимо отправить запрос во многие экземпляры.

Это легко реализовать. С точки зрения реализации он будет более масштабируемым с точки зрения функциональности индикатора выполнения и количества загруженных файлов и общего% загрузки

Answer 3

Наблюдатель является более гибким / масштабируемым. Разве это не странно после того, как вы упомянули шаблон наблюдателя? Скороговорки - это всего лишь руководящие указания, если вам нужно немного изменить их, чтобы они соответствовали вашим потребностям, тогда сделайте это.

Рассмотрим случай, когда у вас есть несколько DownloadManagers (возможно, это неправильный вариант использования для вашей конкретной ситуации). Вам нужно будет зарегистрировать их обоих. Если у вас есть еще больше, вам придется зарегистрировать их все. Довольно длинный список, плюс вам нужно реализовать управление слушателями в Download s

Answer 4

Обратные вызовы FTW. Это проще, и в подавляющем большинстве случаев простота положительно влияет на все остальные аспекты проекта, включая разработку, отладку, оптимизацию, документирование и дальнейшее обслуживание.