Объекты RX - их следует избегать?

У меня была мини-дискуссия по теме в другом потоке, и хотелось бы, чтобы люди вводили "плохие" стороны тем.

Люди, которые часто посещают форум RX, знают, что E.Meijer не любит темы. Несмотря на то, что я глубоко уважаю мнение создателя RX, я довольно часто использовал объекты в нескольких проектах в течение нескольких лет и не имел никаких архитектурных проблем или ошибок из-за них.

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

"Запах кода" и "Не нравится их" должны поддерживаться "прагматичными" примерами - можете ли вы привлечь к себе внимание возможные ситуации, когда использование объекта может привести к ошибке или проблеме? Или, может быть, вы думаете, что они легки и безвредны вообще, - тогда попытайтесь определить область, в которой они будут использоваться.

Ответ 1

Эрик Мейер думает чисто функциональным образом. Субъекты являются изменяемыми переменными Rx. Таким образом, в общем использовании он прав - использование Субъектов - это иногда способ вывести из мышления Функционально, и если вы слишком много используете их, вы пытаетесь свернуться вверх по течению.

Однако! Тема чрезвычайно полезна, когда вы взаимодействуете с не функциональным миром .NET. Обертывание метода события или обратного вызова? Субъекты отлично подходят для этого. Попытка поставить Rx "интерфейс" на какой-то существующий код? Используйте тему!

Ответ 2

Кажется, что многие комментаторы говорят друг за другом.

В прошлый раз, когда я использовал тему Subject, мне нужно было передать делегат промежуточному программному обеспечению в вызове инициализации, чтобы он мог перезвонить мне, когда что-то случилось. У делегата была знакомая подпись args событий, но я не мог использовать FromEvent, потому что не было никакого события.

Мне было плохо, я не видел другого выбора.

В основном я использовал объекты только в том случае, когда я запускаю какое-то событие и помещаю его в мир Rx, или когда мне нужен дескриптор для будущего подписчика, который еще не прибыл. Субъекты позволяют мне связать то, что у меня есть, для более позднего абонента.

Ответ 3

Я использую Subject/Publish, когда реактивные комбинаторы дублируются из-за ленивого eval.

Однако, для случайного использования я чувствую, что Субъекты немного тяжелы - OnNext может быть потенциальной горлышкой бутылки - появляется как горячая точка во время профилирования, возможно, из-за проверки concurrency при нажатии значения подписчикам.

Я чувствую, что это также чище для Observables, которые, как вы знаете, являются горячими по определению.

Ответ 4

Одна из причин, по которой я опасаюсь использовать Subject<T> как часть общедоступного API, заключается в том, что он смешивает проблемы; наблюдатель представляет собой проблему, отличную от наблюдаемой.

Что делать, если какой-либо злоумышленник вызывает OnNext или OnCompleted или OnError на Subject<T>, где он должен был быть наблюдателем?

Даже если это не входит в состав API, и вы убираете его на своем сервере как частное поле поддержки, только тот факт, что он имеет двойную роль, вызывает беспокойство. В случае использования его в качестве резервного поля вы все еще только ожидаете, что он выполнит одну роль/проблему - наблюдаемую. Тем не менее, у него есть потенциал сделать две вещи и это просто душевно тревожит.