En este artículo, aprenderá sobre el patrón de diseño Observer en .NET C# con algunas mejoras.  Definición  del patrón de diseño del observador  El   es uno de los patrones de diseño más importantes y de uso común. patrón de diseño del observador  Primero, revisemos la definición formal del   . patrón de diseño del observador  según  :   documentación de microsoft   El patrón de diseño del observador permite que un suscriptor se registre y reciba notificaciones de un proveedor. Es adecuado para cualquier escenario que requiera notificaciones push. El patrón define un proveedor (también conocido como sujeto u observable) y cero, uno o más observadores. Los observadores se registran con el proveedor y, cada vez que se produce una condición, un evento o un cambio de estado predefinidos, el proveedor notifica automáticamente a todos los observadores llamando a uno de sus métodos. En esta llamada de método, el proveedor también puede proporcionar información del estado actual a los observadores. En .NET, el patrón de diseño del observador se aplica implementando las interfaces genéricas   y   . El parámetro de tipo genérico representa el tipo que proporciona información de notificación. System.IObservable<T> System.IObserver<T>  Entonces, de la definición anterior, podemos entender lo siguiente:  Tenemos dos fiestas o módulos.  El módulo que tiene algún flujo de información para proporcionar. Este módulo se llama   (ya que proporciona información), o   (ya que somete la información al mundo exterior), u   (ya que podría ser observado por el mundo exterior). Proveedor Asunto Observable  El módulo que está interesado en un flujo de información procedente de otro lugar. Este módulo se llama   (ya que observa información).  Observer  Ventajas del patrón de diseño del observador  Como sabemos ahora, el   formula la relación entre los módulos   y   . Lo que hace que el   sea único es que al usarlo puede lograrlo sin tener una relación estrechamente acoplada. patrón de diseño del observador Observable Observer patrón de diseño del observador   Analizando la forma en que funciona el patrón, encontraría lo siguiente:  El   conoce la información mínima necesaria sobre el   . Observable Observador  El   conoce la información mínima necesaria sobre el   . Observador Observable  Incluso el conocimiento mutuo se logra mediante abstracciones, no implementaciones concretas.  Al final, ambos módulos pueden hacer su trabajo y solo su trabajo.   Abstracciones utilizadas  Estas son las   utilizadas para implementar el   en   . abstracciones patrón de diseño del observador .NET C#  IObservable<out T>  Esta es una interfaz   que representa cualquier   . Si quieres saber más sobre Variance en .NET, puedes consultar el artículo  . covariante Observable   Covarianza y contravarianza en .NET C#  Los miembros definidos en esta interfaz son:   public IDisposable Subscribe (IObserver<out T> observer);  Se debe llamar al método   para informar al   que algún   está interesado en su flujo de información. Subscribe Observable observador  El método   devuelve un objeto que implementa la interfaz   . Este objeto podría ser utilizado por el   para darse de baja del flujo de información proporcionado por el   . Una vez hecho esto, el   no será notificado sobre ninguna actualización del flujo de información. Subscribe IDisposable Observador Observable observador  IObserver<en T>  Esta es una interfaz   que representa a cualquier   . Si quieres saber más sobre Variance en .NET, puedes consultar el artículo  . contravariante observador   Covarianza y contravarianza en .NET C#  Los miembros definidos en esta interfaz son:   public void OnCompleted (); public void OnError (Exception error); public void OnNext (T value);  El método   debe ser llamado por el   para informar al   que el flujo de información se completó y el   no debe esperar más información. OnCompleted Observable observador observador  El   debe llamar al método   para informar al   que se ha producido un error. Observable OnError Observer  El   debe llamar al método   para informar al   que una nueva información está lista y se está agregando a la transmisión.  Observable OnNext Observer  Implementación de Microsoft  Ahora, veamos cómo recomienda   implementar el   en C#. Más adelante, le mostraré algunas mejoras menores que implementé yo mismo. Microsoft patrón de diseño Observer  Construiremos una sencilla   . En esta aplicación, tendremos el módulo   (Observable, Provider, Subject) y el módulo   (Observador). aplicación de consola de pronóstico del tiempo WeatherForecast WeatherForecastObserver  Entonces, comencemos a investigar la implementación.  Información meteorológica   namespace Observable { public class WeatherInfo { internal WeatherInfo(double temperature) { Temperature = temperature; } public double Temperature { get; } } }  Esta es la entidad que representa la pieza de información que fluirá en el flujo de información.  Pronóstico del tiempo   using System; using System.Collections.Generic; namespace Observable { public class WeatherForecast : IObservable<WeatherInfo> { private readonly List<IObserver<WeatherInfo>> m_Observers; private readonly List<WeatherInfo> m_WeatherInfoList; public WeatherForecast() { m_Observers = new List<IObserver<WeatherInfo>>(); m_WeatherInfoList = new List<WeatherInfo>(); } public IDisposable Subscribe(IObserver<WeatherInfo> observer) { if (!m_Observers.Contains(observer)) { m_Observers.Add(observer); foreach (var item in m_WeatherInfoList) { observer.OnNext(item); } } return new WeatherForecastUnsubscriber(m_Observers, observer); } public void RegisterWeatherInfo(WeatherInfo weatherInfo) { m_WeatherInfoList.Add(weatherInfo); foreach (var observer in m_Observers) { observer.OnNext(weatherInfo); } } public void ClearWeatherInfo() { m_WeatherInfoList.Clear(); } } }   Lo que podemos notar aquí:  La clase   está implementando   . WeatherForecast IObservable<WeatherInfo>  En la implementación del método   , verificamos si el observador pasado ya estaba registrado antes o no. Si no, lo agregamos a la lista de observadores locales   . Luego, hacemos un bucle en todas las entradas   que tenemos en la lista   local una por una e informamos al observador al respecto llamando al método   del observador. Subscribe m_Observers WeatherInfo m_WeatherInfoList OnNext  Finalmente, devolvemos una nueva instancia de la clase   para que el observador la use para darse de baja del flujo de información. WeatherForecastUnsubscriber  El método   se define para que el módulo principal pueda registrar nuevos   . En el mundo real, esto podría reemplazarse por una   interna programada o un oyente de   u otra cosa que actuaría como fuente de información. RegisterWeatherInfo WeatherInfo llamada de API SignalR Hub  Darse de baja<T>   using System; using System.Collections.Generic; namespace Observable { public class Unsubscriber<T> : IDisposable { private readonly List<IObserver<T>> m_Observers; private readonly IObserver<T> m_Observer; private bool m_IsDisposed; public Unsubscriber(List<IObserver<T>> observers, IObserver<T> observer) { m_Observers = observers; m_Observer = observer; } public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } protected virtual void Dispose(bool disposing) { if (m_IsDisposed) return; if (disposing && m_Observers.Contains(m_Observer)) { m_Observers.Remove(m_Observer); } m_IsDisposed = true; } ~Unsubscriber() { Dispose(false); } } }   Lo que podemos notar aquí:  Esta es una clase base para cualquier usuario que se haya dado de baja.  Implementa   aplicando el   . IDisposable patrón de diseño desechable  A través del constructor, toma la lista completa de Observadores y el Observador para el que se creó.  Al desechar, comprueba si el observador ya existe en la lista completa de observadores. Si es así, lo elimina de la lista.  TiempoPronósticoCancelar suscripción   using System; using System.Collections.Generic; namespace Observable { public class WeatherForecastUnsubscriber : Unsubscriber<WeatherInfo> { public WeatherForecastUnsubscriber( List<IObserver<WeatherInfo>> observers, IObserver<WeatherInfo> observer) : base(observers, observer) { } } }   Lo que podemos notar aquí:  Esto se hereda de la clase   . Unsubscriber<T>  No está ocurriendo ningún manejo especial.  ClimaPronósticoObservador   using System; namespace Observable { public class WeatherForecastObserver : IObserver<WeatherInfo> { private IDisposable m_Unsubscriber; public virtual void Subscribe(WeatherForecast provider) { m_Unsubscriber = provider.Subscribe(this); } public virtual void Unsubscribe() { m_Unsubscriber.Dispose(); } public void OnCompleted() { Console.WriteLine("Completed"); } public void OnError(Exception error) { Console.WriteLine("Error"); } public void OnNext(WeatherInfo value) { Console.WriteLine($"Temperature: {value.Temperature}"); } } }   Lo que podemos notar aquí:  La clase   está implementando   . WeatherForecastObserver IObserver<WeatherInfo>  En el método   , estamos escribiendo la temperatura en la consola. OnNext  En el método   , estamos escribiendo "Completado" en la consola. OnCompleted  En el método   , estamos escribiendo "Error" en la consola. OnError  Definimos el método   para permitir que el módulo principal active el proceso de registro. El objeto de cancelación de suscripción devuelto se guarda internamente para ser utilizado en caso de cancelación de suscripción. void Subscribe(WeatherForecast provider)  Utilizando el mismo concepto, se define el método   y hace uso del objeto de cancelación de suscripción guardado internamente. void Unsubscribe()  Programa   using System; namespace Observable { class Program { static void Main(string[] args) { var provider = new WeatherForecast(); provider.RegisterWeatherInfo(new WeatherInfo(1)); provider.RegisterWeatherInfo(new WeatherInfo(2)); provider.RegisterWeatherInfo(new WeatherInfo(3)); var observer = new WeatherForecastObserver(); observer.Subscribe(provider); provider.RegisterWeatherInfo(new WeatherInfo(4)); provider.RegisterWeatherInfo(new WeatherInfo(5)); observer.Unsubscribe(); provider.RegisterWeatherInfo(new WeatherInfo(6)); observer.Subscribe(provider); provider.RegisterWeatherInfo(new WeatherInfo(7)); Console.ReadLine(); } } }   Lo que podemos notar aquí:  Creamos una instancia del proveedor.  Luego registró 3 piezas de información.  Hasta este momento, no se debe registrar nada en la consola ya que no se definen observadores.  Luego creó una instancia del observador.  Luego suscribió al observador a la transmisión.  En este momento, deberíamos encontrar 3 temperaturas registradas en la consola. Esto se debe a que cuando el observador se suscribe, se le notifica sobre la información ya existente y, en nuestro caso, son 3 piezas de información.  Luego registramos 2 piezas de información.  Entonces, obtenemos 2 mensajes más registrados en la consola.  Luego nos damos de baja.  Luego registramos 1 pieza de información.  Sin embargo, esta información no se registraría en la consola ya que el observador ya se había dado de baja.  Entonces el observador se suscribe de nuevo.  Luego registramos 1 pieza de información.  Entonces, esta información se registra en la consola.  Finalmente, ejecutar esto debería terminar con este resultado:   Mi implementación extendida  Cuando revisé la implementación de Microsoft, encontré algunas preocupaciones. Por lo tanto, decidí hacer algunos cambios menores.  IExtendedObservable<out T>   using System; using System.Collections.Generic; namespace ExtendedObservable { public interface IExtendedObservable<out T> : IObservable<T> { IReadOnlyCollection<T> Snapshot { get; } IDisposable Subscribe(IObserver<T> observer, bool withHistory); } }   Lo que podemos notar aquí:  La interfaz   amplía la interfaz   . IExtendedObservable<out T> IObservable<T>  es   . Si quieres saber más sobre esto, puedes consultar el artículo  . covariante   Covarianza y contravarianza en .NET C#  Definimos la propiedad   para permitir que otros módulos obtengan una lista instantánea de entradas de información ya existentes sin tener que suscribirse. IReadOnlyCollection<T> Snapshot  También definimos el método   con un parámetro   adicional para que el observador pueda decidir si desea recibir notificaciones sobre las entradas de información ya existentes o no en el momento de la suscripción. IDisposable Subscribe(IObserver<T> observer, bool withHistory) bool withHistory  darse de baja   using System; namespace ExtendedObservable { public class Unsubscriber : IDisposable { private readonly Action m_UnsubscribeAction; private bool m_IsDisposed; public Unsubscriber(Action unsubscribeAction) { m_UnsubscribeAction = unsubscribeAction; } public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } protected virtual void Dispose(bool disposing) { if (m_IsDisposed) return; if (disposing) { m_UnsubscribeAction(); } m_IsDisposed = true; } ~Unsubscriber() { Dispose(false); } } }   Lo que podemos notar aquí:  Ahora, la clase   no es genérica. Unsubscriber  Esto se debe a que ya no necesita saber el tipo de entidad de información.  En lugar de tener acceso a la lista completa de Observadores y el Observador para el que se creó, simplemente notifica al Observable cuando se elimina y el Observable maneja el proceso de cancelación del registro por sí mismo.  De esta manera, está haciendo menos que antes y solo está haciendo su trabajo.  TiempoPronósticoCancelar suscripción   using System; using System.Collections.Generic; namespace ExtendedObservable { public class WeatherForecastUnsubscriber : Unsubscriber { public WeatherForecastUnsubscriber( Action unsubscribeAction) : base(unsubscribeAction) { } } }   Lo que podemos notar aquí:  Eliminamos la parte   de   . <T> Unsubscriber<T>  Y ahora el constructor toma una   para ser llamado en caso de disposición. Action  Pronóstico del tiempo   using System; using System.Collections.Generic; namespace ExtendedObservable { public class WeatherForecast : IExtendedObservable<WeatherInfo> { private readonly List<IObserver<WeatherInfo>> m_Observers; private readonly List<WeatherInfo> m_WeatherInfoList; public WeatherForecast() { m_Observers = new List<IObserver<WeatherInfo>>(); m_WeatherInfoList = new List<WeatherInfo>(); } public IReadOnlyCollection<WeatherInfo> Snapshot => m_WeatherInfoList; public IDisposable Subscribe(IObserver<WeatherInfo> observer) { return Subscribe(observer, false); } public IDisposable Subscribe(IObserver<WeatherInfo> observer, bool withHistory) { if (!m_Observers.Contains(observer)) { m_Observers.Add(observer); if (withHistory) { foreach (var item in m_WeatherInfoList) { observer.OnNext(item); } } } return new WeatherForecastUnsubscriber( () => { if (m_Observers.Contains(observer)) { m_Observers.Remove(observer); } }); } public void RegisterWeatherInfo(WeatherInfo weatherInfo) { m_WeatherInfoList.Add(weatherInfo); foreach (var observer in m_Observers) { observer.OnNext(weatherInfo); } } public void ClearWeatherInfo() { m_WeatherInfoList.Clear(); } } }   Lo que podemos notar aquí:  Es casi lo mismo excepto por la propiedad   que devuelve la lista interna   pero como   . IReadOnlyCollection<WeatherInfo> Snapshot m_WeatherInfoList IReadOnlyCollection  Y el método   que utiliza el parámetro   . IDisposable Subscribe(IObserver<WeatherInfo> observer, bool withHistory) withHistory  ClimaPronósticoObservador   using System; namespace ExtendedObservable { public class WeatherForecastObserver : IObserver<WeatherInfo> { private IDisposable m_Unsubscriber; public virtual void Subscribe(WeatherForecast provider) { m_Unsubscriber = provider.Subscribe(this, true); } public virtual void Unsubscribe() { m_Unsubscriber.Dispose(); } public void OnCompleted() { Console.WriteLine("Completed"); } public void OnError(Exception error) { Console.WriteLine("Error"); } public void OnNext(WeatherInfo value) { Console.WriteLine($"Temperature: {value.Temperature}"); } } }  Lo que podemos notar aquí es que es casi lo mismo a excepción de   que ahora decide si debe   con el historial o no. Subscribe(WeatherForecast provider) Subscribe  Programa   using System; namespace ExtendedObservable { class Program { static void Main(string[] args) { var provider = new WeatherForecast(); provider.RegisterWeatherInfo(new WeatherInfo(1)); provider.RegisterWeatherInfo(new WeatherInfo(2)); provider.RegisterWeatherInfo(new WeatherInfo(3)); var observer = new WeatherForecastObserver(); observer.Subscribe(provider); provider.RegisterWeatherInfo(new WeatherInfo(4)); provider.RegisterWeatherInfo(new WeatherInfo(5)); observer.Unsubscribe(); provider.RegisterWeatherInfo(new WeatherInfo(6)); observer.Subscribe(provider); provider.RegisterWeatherInfo(new WeatherInfo(7)); Console.ReadLine(); } } }  Es lo mismo que antes.  Finalmente, ejecutar esto debería terminar con el mismo resultado que antes:   Que sigue  Ahora, conoce los conceptos básicos del   en .NET C#. Sin embargo, este no es el final de la historia. patrón de diseño del observador  Hay bibliotecas construidas sobre las interfaces   e   que brindan características y capacidades más interesantes que pueden resultarle útiles. IObservable<T> IObserver<T>  Una de estas bibliotecas es la  biblioteca. Consiste en un conjunto de métodos de extensión y operadores de secuencia estándar de LINQ para admitir la programación asíncrona.   Extensiones reactivas para .NET (Rx)  Por lo tanto, lo animo a explorar estas bibliotecas y probarlas. Estoy seguro de que te gustaría alguno de ellos.   También publicado  aquí.

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Check my links 😀

My HackerNoon Stories

My Medium Articles

Buy Me a Coffee

Buy Me a Gift

Check My Links

Hire Me

Este audio es producido en el idioma original de la historia!

Una guía esencial para el patrón de diseño del observador en .NET C#

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

El modelo Bitcoin UTXO, impulsando un ecosistema único

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

El modelo Bitcoin UTXO, impulsando un ecosistema único

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps