RX Предметы - их следует избегать? - PullRequest
22 голосов
/ 15 февраля 2012

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

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

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

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

Ответы [ 4 ]

25 голосов
/ 16 февраля 2012

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

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

6 голосов
/ 16 февраля 2012

Похоже, многие комментаторы говорят друг за другом.

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

Я не чувствовал себя плохо по этому поводу - я не видел другого выбора.

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

2 голосов
/ 16 февраля 2012

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

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

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

1 голос
/ 17 июля 2016

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

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

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

...