NOTA: Si tiene acceso a C # 5.0 desatado , lea las "Limitaciones en el uso simple de delegados" en el Capítulo 18 titulado "Eventos" para comprender mejor las diferencias entre los dos.
Siempre me ayuda a tener un ejemplo simple y concreto. Así que aquí hay uno para la comunidad. Primero muestro cómo puedes usar delegados solos para hacer lo que los Eventos hacen por nosotros. Luego muestro cómo funcionaría la misma solución con una instancia de EventHandler. Y luego explico por qué NO queremos hacer lo que explico en el primer ejemplo. Esta publicación fue inspirada por un artículo de John Skeet.
Ejemplo 1: uso de delegado público
Supongamos que tengo una aplicación WinForms con un solo cuadro desplegable. El menú desplegable está vinculado a un List<Person>. Donde la persona tiene propiedades de Id, Nombre, Apodo, HairColor. En el formulario principal hay un control de usuario personalizado que muestra las propiedades de esa persona. Cuando alguien selecciona a una persona en el menú desplegable, las etiquetas de la actualización de control de usuario muestran las propiedades de la persona seleccionada.
Así es como funciona eso. Tenemos tres archivos que nos ayudan a armar esto:
- Mediator.cs: la clase estática contiene los delegados
- Form1.cs - formulario principal
- DetailView.cs: el control de usuario muestra todos los detalles
Aquí está el código relevante para cada una de las clases:
class Mediator
{
public delegate void PersonChangedDelegate(Person p); //delegate type definition
public static PersonChangedDelegate PersonChangedDel; //delegate instance. Detail view will "subscribe" to this.
public static void OnPersonChanged(Person p) //Form1 will call this when the drop-down changes.
{
if (PersonChangedDel != null)
{
PersonChangedDel(p);
}
}
}
Aquí está nuestro control de usuario:
public partial class DetailView : UserControl
{
public DetailView()
{
InitializeComponent();
Mediator.PersonChangedDel += DetailView_PersonChanged;
}
void DetailView_PersonChanged(Person p)
{
BindData(p);
}
public void BindData(Person p)
{
lblPersonHairColor.Text = p.HairColor;
lblPersonId.Text = p.IdPerson.ToString();
lblPersonName.Text = p.Name;
lblPersonNickName.Text = p.NickName;
}
}
Finalmente tenemos el siguiente código en nuestro Form1.cs. Aquí estamos llamando a OnPersonChanged, que llama a cualquier código suscrito al delegado.
private void comboBox1_SelectedIndexChanged(object sender, EventArgs e)
{
Mediator.OnPersonChanged((Person)comboBox1.SelectedItem); //Call the mediator's OnPersonChanged method. This will in turn call all the methods assigned (i.e. subscribed to) to the delegate -- in this case `DetailView_PersonChanged`.
}
Okay. Así es como lo haría funcionar sin usar eventos y solo con delegados . Simplemente ponemos un delegado público en una clase; puede hacerlo estático o un singleton, o lo que sea. Excelente.
PERO, PERO, PERO, no queremos hacer lo que acabo de describir arriba. Porque los campos públicos son malos por muchas, muchas razones. ¿Entonces, cuales son nuestras opciones? Como describe John Skeet, estas son nuestras opciones:
- Una variable delegada pública (esto es lo que acabamos de hacer arriba. No hagas esto. Solo te dije arriba por qué es malo)
- Coloque el delegado en una propiedad con un get / set (el problema aquí es que los suscriptores podrían anularse entre sí, por lo que podríamos suscribir un montón de métodos al delegado y luego podríamos decir accidentalmente
PersonChangedDel = null, eliminando todas las otras suscripciones. Otro problema que queda aquí es que, dado que los usuarios tienen acceso al delegado, pueden invocar los objetivos en la lista de invocación; no queremos que los usuarios externos tengan acceso a cuándo realizar nuestros eventos.
- Una variable delegada con los métodos AddXXXHandler y RemoveXXXHandler
Esta tercera opción es esencialmente lo que nos brinda un evento. Cuando declaramos un EventHandler, nos da acceso a un delegado, no públicamente, no como una propiedad, sino que llamamos a un evento que simplemente agrega / elimina accesores.
Veamos cómo se ve el mismo programa, pero ahora usando un Evento en lugar del delegado público (también he cambiado nuestro Mediador a un singleton):
Ejemplo 2: con EventHandler en lugar de un delegado público
Mediador:
class Mediator
{
private static readonly Mediator _Instance = new Mediator();
private Mediator() { }
public static Mediator GetInstance()
{
return _Instance;
}
public event EventHandler<PersonChangedEventArgs> PersonChanged; //this is just a property we expose to add items to the delegate.
public void OnPersonChanged(object sender, Person p)
{
var personChangedDelegate = PersonChanged as EventHandler<PersonChangedEventArgs>;
if (personChangedDelegate != null)
{
personChangedDelegate(sender, new PersonChangedEventArgs() { Person = p });
}
}
}
Tenga en cuenta que si usa F12 en EventHandler, le mostrará que la definición es solo un delegado genérico con el objeto adicional "remitente":
public delegate void EventHandler<TEventArgs>(object sender, TEventArgs e);
El control del usuario:
public partial class DetailView : UserControl
{
public DetailView()
{
InitializeComponent();
Mediator.GetInstance().PersonChanged += DetailView_PersonChanged;
}
void DetailView_PersonChanged(object sender, PersonChangedEventArgs e)
{
BindData(e.Person);
}
public void BindData(Person p)
{
lblPersonHairColor.Text = p.HairColor;
lblPersonId.Text = p.IdPerson.ToString();
lblPersonName.Text = p.Name;
lblPersonNickName.Text = p.NickName;
}
}
Finalmente, aquí está el código Form1.cs:
private void comboBox1_SelectedIndexChanged(object sender, EventArgs e)
{
Mediator.GetInstance().OnPersonChanged(this, (Person)comboBox1.SelectedItem);
}
Debido a que EventHandler quiere y EventArgs como parámetro, creé esta clase con solo una propiedad:
class PersonChangedEventArgs
{
public Person Person { get; set; }
}
Esperemos que eso muestre un poco sobre por qué tenemos eventos y cómo son diferentes, pero funcionalmente iguales, como delegados.