system.reactive - Sujetos RX: ¿deben ser evitados?
seo tags (4)
Erik Meijer piensa de una manera puramente funcional: los sujetos son las variables mutables de Rx. Por lo tanto, en términos generales, tiene razón: el uso de Sujetos es a veces una manera de salir del Pensamiento Funcionalmente, y si los usa demasiado, está tratando de remar hacia arriba.
¡Sin embargo! Los temas son extremadamente útiles cuando estás interactuando con el mundo no funcional de .NET. Envolviendo un evento o método de devolución de llamada? Los temas son geniales para eso. ¿Tratando de poner una "interfaz" Rx en algún código existente? ¡Usa un tema!
He tenido una mini-discusión sobre el tema en otro hilo, y me gustaría tener la opinión de la gente sobre los aspectos "malos" de los temas.
Las personas que frecuentan el foro de RX saben que a E.Meijer no le gustan los temas . Si bien tengo un profundo respeto por la opinión del creador de RX, he estado usando los Temas de forma bastante extensa en varios proyectos durante un par de años y no he tenido ningún problema arquitectónico o un error debido a ellos.
La única "trampa" con los sujetos que puedo nombrar es que no son "reutilizables": después de que haya completado un observable en un sujeto, debe volver a crear una instancia, antes de que los nuevos suscriptores puedan recibir eventos de este.
El "olor a código" y "No me gustan" tienen que estar respaldados por ejemplos "pragmáticos". ¿Puede llamar nuestra atención sobre posibles situaciones cuando el uso de un sujeto puede provocar un error o un problema? O tal vez piense que son fáciles e inofensivos por completo, luego intente definir un área donde se van a usar.
Parece que muchos comentaristas están hablando uno al lado del otro.
La última vez que utilicé un Asunto fue cuando tuve que pasar un delegado a un middleware en una llamada de inicialización para que me devolviera la llamada cuando ocurriera algo. El delegado tenía la firma de args del evento familiar, pero no podía usar FromEvent porque no había ningún evento.
No me sentí mal por eso, no vi ninguna otra opción.
Básicamente, utilicé Sujetos solo cuando originé algún evento y lo coloqué en el mundo de Rx, o cuando necesito un identificador para algún suscriptor futuro que aún no haya llegado. Los temas me permiten vincular lo que tengo ahora con un suscriptor posterior.
Una de las razones por las que desconfiaría de usar un Subject<T> como parte de la API pública es que mezcla preocupaciones; Un observador es una preocupación distinta de lo observable.
¿Qué OnNext si un observador OnNext llama a OnNext u OnCompleted u OnError en el Subject<T> donde se suponía que solo era un observador ?
Incluso si no forma parte de la API, y la guardas en tu servidor como un campo de respaldo privado, solo el hecho de que tenga una doble función es preocupante. En el caso de usarlo como un campo de respaldo, solo espera que desempeñe una función / preocupación: la de un observable. Sin embargo, tiene el potencial de hacer dos cosas y eso es simplemente perturbador mental.
Uso Subject / Publish siempre que los combinadores reactivos se dupliquen debido a la perezosa eval.
Sin embargo, para un uso informal, siento que los sujetos son un poco pesados (OnNext podría ser un posible cuello de botella) aparece como un punto de acceso durante el perfilado, tal vez debido a las verificaciones de concurrencia al tiempo que aumenta el valor para los suscriptores.
Siento que también es más limpio para los Observables que saben que son calientes por definición.