Ответ 1
EDITED: с комментарием @Alrid
TL;DR
public abstract class Subscriber<T> implements Observer<T>, Subscription
Итак, Subscriber является реализацией Observer, с дополнительной семантикой по подписке (больше о не-подписке).
Код в вашем вопросе просто показывает, что он передает интерфейс Observer
вместо реализации (обычная практика программирования).
Также этот код возвращает Subscription
, что может быть связано с тем, что автор этого кода считал, что клиент должен иметь доступ только к Subscription
методам без доступа к элементам, созданным наблюдаемым. Это может быть ошибка программиста.
длинный рассказ
Действительно, вы должны прочитать содержание этого веб-сайта (или книги): http://www.introtorx.com Речь идет о Rx.Net, но концепции такие же, они были созданы Эриком Мейджером и разработчиками RxJava, которые следуют им (если применимо к Язык Java).
Эта страница вас будет интересовать (это вторая глава): KeyTypes
Здесь вы прочтете в первых абзацах:
Существует два ключевых типа, которые следует понимать при работе с Rx и подмножество вспомогательных типов, которые помогут вам более эффективно изучить Rx. IObserver и IObservable образуют основные строительные блоки для Rx, а реализации ISubject уменьшают кривую обучения для разработчиков, новых для Rx.
...
По существу Rx строится на основе шаблона Observer..NET уже предоставляет некоторые другие способы реализации шаблона Observer, такие как делегаты многоадресной передачи или события (которые обычно являются делегатами многоадресной рассылки).
Даже если типы /API немного отличаются друг от друга, вы узнаете много с этой книгой, возможно, больше, чем с некоторыми блогами.
Что эта книга не говорит (... потому что она находится в реализации RxJava)
Основной разработчик RxJava в это время ввел небольшое изменение (см. PR # 792), что позволило различать два типа контрактов:
- уведомление →
Observer
- (un) подписка →
Subscription
Это изменение позволило лучше выразить/разделить эти проблемы с реализующими классами библиотеки RxJava.
Однако как пользователь библиотеки, использование фактических реализаций библиотеки RxJava должно быть достаточно хорошим.
Реализация абонента требует гораздо больше знаний, работы и ухода, действительно, семантика подписки очень важна в зависимости от типа наблюдаемого источника (горячая или холодная? Дорогая, чтобы создать?)
Выявление Subscriber
, а не Observer
в таких случаях, как указано выше, не будет мешать коду в большинстве случаев, но это не предназначено для него, если не нужны семантики без подписки. Но в итоге реализация Subscriber
и может включать в себя некоторые подводные камни, такие как:
- тратить ресурсы на функциональность, которую вы не будете использовать
- не может наследовать другой класс
- написать неверный код без подписки
- скопировать/вставить код с неправильным кодом или правильным кодом, написанным для другого контекста.