Przedmioty RX - czy należy ich unikać?

Question

W innym wątku miałem mini-discussion on the topic i chciałbym, aby ludzie mieli dostęp do "złych" stron obiektów.

Osoby, które często odwiedzają forum RX wiedzą, że E.Meijer does not like Subjects. Chociaż mam najgłębszy szacunek dla opinii twórcy RX, od dłuższego czasu używam przedmiotów w wielu projektach od kilku lat i nie miałem żadnego problemu architektonicznego lub błędu z ich powodu.

Jedyną "pułapką" związaną z tematami, które mogę nazwać, jest to, że nie są one "wielokrotnego użytku" - po ukończeniu obserwowalnego przedmiotu, należy go ponownie utworzyć, zanim nowi subskrybenci mogą odbierać zdarzenia z niego.

"Zapach kodu" i "Nie lubię ich" muszą być wspierane przez "pragmatyczne" przykłady - czy możesz zwrócić uwagę na możliwe sytuacje, w których korzystanie z tematu może prowadzić do błędu lub problemu? A może uważasz, że są one łatwe i nieszkodliwe, a następnie spróbuj zdefiniować obszar, w którym mają być używane.

Answer 1

Erik Meijer myśli w sposób czysto funkcjonalny - Przedmioty są zmiennymi zmiennymi Rx. Tak więc, w ogólnym użyciu ma rację - używanie przedmiotów jest czasem sposobem na wyrzucenie Funkcjonalnego Myślenia, a jeśli używasz ich za dużo, próbujesz wiosłować w górę rzeki.

Jednak! Temat jest niezwykle przydatny, gdy łączysz się ze środowiskami niefunkcjonalnymi .NET. Zawijanie zdarzenia lub metody zwrotnej? Przedmioty są do tego świetne. Próbujesz umieścić interfejs Rx na istniejącym kodzie? Użyj tematu!

Answer 2

Używam Subject/Publish ilekroć reaktywne kombinatory są powielane z powodu leniwego ewaluacji.

Jednak dla zwykłego użytku uważam, że przedmioty są nieco ciężkie - OnNext może być potencjalnym szyjką butelki - pojawia się jako hotspot podczas profilowania, być może z powodu kontroli równoczesnej, podczas przesyłania wartości do subskrybentów.

Czuję, że jest również czystszy dla obserwatorów, które z definicji są gorące.

Answer 3

Wygląda na to, że wielu komentatorów przemawia obok siebie.

Ostatni raz użyłem tematu, kiedy musiałem przekazać delegata do oprogramowania pośredniego w wywołaniu inicjalizacyjnym, aby mógł oddzwonić, gdy coś się stanie. Delegat miał znaną sygnaturę zdarzenia, ale nie mogłem użyć FromEvent, ponieważ nie było żadnego zdarzenia.

Nie czułem się źle - nie widziałem innego wyboru.

Zasadniczo użyłem Przedmioty tylko wtedy, gdy jestem źródłem jakiegoś zdarzenia i wprowadzanie go do świata Rx, lub gdy potrzebuję uchwyt do niektórych przyszłych subskrybentów, którzy jeszcze nie przybyli. Przedmioty pozwalają mi połączyć to, co mam teraz z późniejszym subskrybentem.

Answer 4

Jedną z przyczyn, dla których nie chciałbym używać numeru Subject<T> jako części publicznego interfejsu API, jest mieszanie problemów; obserwator jest problemem odrębnym od obserwowalnego.

Co jeśli niektóre miscreant obserwator wzywa OnNext lub OnCompleted lub OnError na Subject<T> gdzie tylko miał być obserwator?

Nawet jeśli nie jest częścią API i umieszczasz ją na serwerze jako prywatne pole podkładu, sam fakt, że ma podwójną rolę, jest niepokojący. W przypadku korzystania z niego jako zaplecza, wciąż oczekuje się, że wykona jedną rolę/problem - obserwowalne. Jednak ma potencjał, aby zrobić dwie rzeczy i to jest po prostu niepokojące psychicznie.