Есть ли причина использовать шаблон Observer над широковещательным приемником?

Недавно я начал работать над проектом Android, который прекратил использование Broadcast Receiver в пользу «Listeners». Действительно, эта реализация использует шаблон наблюдателя, подобный этой статье (в моем случае есть даже .aidl).

Поэтому я не понимаю, почему. Меня учили, что композиция лучше, чем наследование. Для меня широковещательным приемником является композиция. Это родная функция Android, которую должен знать каждый разработчик Android. Итак, почему, есть ли причина, по которой я должен отказаться от своих вещательных приемников в пользу шаблона наблюдателя? Является ли это всего лишь плохим дизайном для моих команд?

Обновить:

Я нашел комментарий, в котором говорится, что это следует за Single Responsiblity , однако я не уверен, что следую, поскольку любой класс, реализующий слушателя, должен иметь другие обязанности (например, действия, которые управляют жизненным циклом пользовательского интерфейса).

Использование BroadcastReceiver s позволяет отделить один компонент от другого. Отправитель ничего не знает о получателях своего сообщения. Он просто отправляет трансляции и не заботится о том, было ли получено и обработано. Та же концепция имеет шину событий (например, Отто ). Но у глобальных BroadcastReceiver есть небольшие накладные расходы, потому что они по своей природе являются объектами кросс-приложений. Поэтому, если вам нужно отправлять события только внутри одного приложения, я бы использовал LocalBroadcastManager или автобус событий, который я указал ранее.

В случае использования слушателей (наблюдателей) компоненты становятся жестко связанными, потому что отправитель имеет ссылку на приемник и знает о его природе (какой интерфейс прослушивает слушатель) и должен проверить, не является ли слушатель не нулевым.

Да, я видел 100 раз, что BroadcastReceiver использует шаблон проектирования Observer, но все же не согласен с этим. Прежде всего, определение шаблона проектирования Observer: «Шаблон наблюдателя – это шаблон разработки программного обеспечения, в котором объект, называемый субъектом, поддерживает список своих иждивенцев, называемых наблюдателями, и автоматически уведомляет их о любых изменениях состояния, обычно Путем вызова одного из их методов ». Какой объект наблюдается в BroadcastReceiver? Ctx.registerReceiver (приемник, фильтр) не предоставляет информацию о каком-либо объекте. Широковещательный приемник в своей идее не предназначен для уведомления числа классов об изменениях в любом объекте – это просто слушатель механизма вещания, но не только. Чтобы получать уведомления об изменениях, вы должны зарегистрировать объект-получатель с фильтрами. Вы не получите NO NOTIFICATION после того, как вы не установили фильтры с приемниками. Поэтому ваши приемники должны быть выбраны в отношении действий намерения, чтобы ваш onReceive (Intent, …) был запущен. По крайней мере, я вижу здесь селекторный рисунок. Но не только это. Что действительно транслируется? Он распространяет намерения, отправленные как концентратор, и выбирает зарегистрированные приемники фильтрами действия. Теперь просмотрите определение шаблона посредника ( https://sourcemaking.com/design_patterns/mediator ). Это не так? Механизм вещания реализует навыки, позволяющие взаимодействовать с объектом, когда отправитель ничего не знает о слушателе и слушателе, говорит, что его нужно слушать независимо от того, кто его отправил. Не является посредником. В принципе, BroadcastReceiver является неделимой частью механизма Broadcast для Android. Разделение BroadcastReceiver от всего механизма просто неверно. Из-за того, что потребитель JMS-сообщений является неделимой частью JMS. Намерение, используемое в широковещательном приемнике, предназначено для передачи действия и набора аргументов (параметров, что еще). Он обычно используется для передачи действия (!) С данными. Действительно, это объект данных для команды. Для сравнения рассмотрим действительно хорошо известный случай шаблона Observer в Android – ContentObserver. Как это работает: getContentResolver (). RegisterContentObserver (SOME_URI, true, yourObserver); Смотрите, слушатель подключен к выделенному ресурсу, а не для прослушивания общего назначения. Он запускается после изменения содержимого (вы отправили уведомление о чем-либо?) И уведомляет, что изменилось (Uri). Да, это НАБЛЮДАТЕЛЬ. Он уведомляет об изменении объекта, а наблюдатель-наблюдатель видит, что изменяется в наблюдаемом объекте. Является ли это моделью работы Broadcast ???? В трансляции я вижу элементы как наименьшее из медиаторов, селекторов и DTO.