Compartir a través de

Prácticas recomendadas del Observer Design Pattern

En .NET, el patrón de diseño de observador se implementa como un conjunto de interfaces. La System.IObservable<T> interfaz representa el proveedor de datos, que también es responsable de proporcionar una IDisposable implementación que permita a los observadores cancelar la suscripción de las notificaciones. La System.IObserver<T> interfaz representa el observador. En este tema se describen los procedimientos recomendados que deben seguir los desarrolladores al implementar el patrón de diseño de observador mediante estas interfaces.

Subprocesos

Normalmente, un proveedor implementa el IObservable<T>.Subscribe método agregando un observador determinado a una lista de suscriptores representada por algún objeto de colección e implementa el IDisposable.Dispose método quitando un observador determinado de la lista de suscriptores. Un observador puede llamar a estos métodos en cualquier momento. Además, dado que el contrato de proveedor/observador no especifica quién es el responsable de cancelar la suscripción después del método de devolución de llamada IObserver<T>.OnCompleted, el proveedor y el observador pueden intentar quitar el mismo miembro de la lista. Debido a esta posibilidad, ambos métodos Subscribe y Dispose deben ser seguros para subprocesos. Normalmente, esto implica el uso de una colección simultánea o un bloqueo. Las implementaciones que no son seguras para hilos deben documentarlo explícitamente.

Todas las garantías adicionales deben especificarse en una capa sobre el contrato de proveedor o observador. Los implementadores deben señalar claramente cuando imponen requisitos adicionales para evitar confusiones de usuario sobre el contrato de observador.

Controlar las excepciones

Debido al acoplamiento flexible entre un proveedor de datos y un observador, las excepciones del patrón de diseño del observador están pensadas para ser informativos. Esto afecta a cómo los proveedores y observadores controlan las excepciones en el patrón de diseño del observador.

El proveedor: invocación del método OnError

El OnError método está pensado como un mensaje informativo para los observadores, al igual que el IObserver<T>.OnNext método . Sin embargo, el OnNext método está diseñado para proporcionar a un observador datos actuales o actualizados, mientras que el OnError método está diseñado para indicar que el proveedor no puede proporcionar datos válidos.

El proveedor debe seguir estos procedimientos recomendados al controlar excepciones y llamar al método OnError:

  • El proveedor debe controlar sus propias excepciones si tiene requisitos específicos.

  • El proveedor no debe esperar ni requerir que los observadores controlen excepciones de una manera determinada.

  • El proveedor debe llamar al OnError método cuando controla una excepción que pone en peligro su capacidad de proporcionar actualizaciones. La información sobre estas excepciones se puede pasar al observador. En otros casos, no es necesario notificar a los observadores una excepción.

Una vez que el proveedor llama al OnError método o IObserver<T>.OnCompleted , no debe haber más notificaciones y el proveedor puede cancelar la suscripción de sus observadores. Sin embargo, los observadores también pueden cancelar su suscripción en cualquier momento, tanto antes como después de recibir una notificación de OnError o IObserver<T>.OnCompleted. El patrón de diseño del observador no determina si el proveedor o el observador son responsables de anular la suscripción; por lo tanto, existe la posibilidad de que ambos intenten cancelar la suscripción. Normalmente, cuando los observadores cancelan la suscripción, se quitan de una colección de suscriptores. En una aplicación de un único subproceso, la implementación de IDisposable.Dispose debe asegurarse de la validez de una referencia de objeto y de que el objeto es miembro de la colección de suscriptores antes de intentar quitarlo. En una aplicación multihilo, se debe usar un objeto de colección seguro para hilos, como un objeto System.Collections.Concurrent.BlockingCollection<T>.

El observador: implementación del método OnError

Cuando un observador recibe una notificación de error de un proveedor, el observador debe tratar la excepción como informativo y no debe ser necesaria para realizar ninguna acción concreta.

El observador debe seguir estos procedimientos recomendados al responder a una OnError llamada de método desde un proveedor:

  • El observador no debe lanzar excepciones desde sus implementaciones de interfaz, como OnNext o OnError. No obstante, si el observador genera excepciones, no debe esperar que se controlen.

  • Para conservar la pila de llamadas, un observador que desee producir un objeto Exception pasado a su método OnError, debe encapsular la excepción antes generarla. Se debe usar un objeto de excepción estándar para este fin.

Procedimientos recomendados adicionales

Si se intenta anular el registro en el IObservable<T>.Subscribe método, se puede producir una referencia nula. Por lo tanto, se recomienda evitar esta práctica.

Aunque es posible adjuntar un observador a varios proveedores, el patrón recomendado es asociar una IObserver<T> instancia a una IObservable<T> sola instancia.

Consulte también