NOTA: Se você tiver acesso ao C # 5.0 Unleashed , leia as "Limitações no uso simples de delegados" no capítulo 18, intitulado "Eventos" para entender melhor as diferenças entre os dois.
Sempre me ajuda a ter um exemplo simples e concreto. Então aqui está um para a comunidade. Primeiro, mostro como você pode usar delegados sozinhos para fazer o que os Eventos fazem por nós. Então eu mostro como a mesma solução funcionaria com uma instância de EventHandler. E então eu explico por que não queremos fazer o que explico no primeiro exemplo. Este post foi inspirado em um artigo de John Skeet.
Exemplo 1: Usando delegado público
Suponha que eu tenha um aplicativo WinForms com uma única caixa suspensa. O menu suspenso está vinculado a um List<Person>. Onde Person tem propriedades de Id, Name, NickName, HairColor. No formulário principal, há um controle de usuário personalizado que mostra as propriedades dessa pessoa. Quando alguém seleciona uma pessoa no menu suspenso, os rótulos na atualização de controle do usuário mostram as propriedades da pessoa selecionada.
Aqui está como isso funciona. Temos três arquivos que nos ajudam a montar isso:
- Mediator.cs - classe estática mantém os delegados
- Form1.cs - formulário principal
- DetailView.cs - o controle do usuário mostra todos os detalhes
Aqui está o código relevante para cada uma das classes:
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);
}
}
}
Aqui está o nosso controle de usuário:
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, temos o seguinte código em nosso Form1.cs. Aqui estamos chamando OnPersonChanged, que chama qualquer código inscrito no 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`.
}
Está bem. Então é assim que você faria isso funcionar sem usar eventos e apenas usando delegados . Acabamos de colocar um representante público em uma classe - você pode torná-lo estático ou único, ou o que for. Ótimo.
MAS, MAS, MAS, nós não queremos fazer o que acabei de descrever acima. Porque os campos públicos são ruins por muitos, muitos motivos. Então, quais são nossas opções? Como John Skeet descreve, aqui estão nossas opções:
- Uma variável pública delegada (foi o que acabamos de fazer acima. Não faça isso. Acabei de lhe dizer por que é ruim)
- Coloque o delegado em uma propriedade com um get / set (o problema aqui é que os assinantes podem se substituir - para que possamos assinar vários métodos para o delegado e, em seguida, acidentalmente digamos
PersonChangedDel = null, eliminando todas as outras assinaturas. outro problema que permanece aqui é que, como os usuários têm acesso ao delegado, eles podem invocar os destinos na lista de chamadas - não queremos que usuários externos tenham acesso a quando criar nossos eventos.
- Uma variável delegada com os métodos AddXXXHandler e RemoveXXXHandler
Esta terceira opção é essencialmente o que um evento nos oferece. Quando declaramos um EventHandler, ele nos dá acesso a um delegado - não publicamente, não como uma propriedade, mas como isso chamamos de um evento que acabou de adicionar / remover acessadores.
Vamos ver como é o mesmo programa, mas agora usando um Evento em vez do representante público (eu também mudei nosso Mediador para um singleton):
Exemplo 2: Com EventHandler em vez de um representante 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 });
}
}
}
Observe que se você F12 no EventHandler, ele mostrará que a definição é apenas um delegado genérico com o objeto "remetente" extra:
public delegate void EventHandler<TEventArgs>(object sender, TEventArgs e);
O Controle do Usuário:
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, aqui está o código Form1.cs:
private void comboBox1_SelectedIndexChanged(object sender, EventArgs e)
{
Mediator.GetInstance().OnPersonChanged(this, (Person)comboBox1.SelectedItem);
}
Como o EventHandler deseja e EventArgs como parâmetro, eu criei essa classe com apenas uma propriedade:
class PersonChangedEventArgs
{
public Person Person { get; set; }
}
Espero que isso mostre um pouco sobre por que temos eventos e como eles são diferentes - mas funcionalmente iguais - como delegados.