Compartilhar via


Design de eventos

Observação

Este conteúdo é reimpresso com permissão da Pearson Education, Inc. de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition. Essa edição foi publicada em 2008 e, desde então, o livro foi totalmente revisado na terceira edição. Algumas das informações nesta página podem estar desatualizadas.

Os eventos são a forma mais usada de retornos de chamada (constructos que permitem que a estrutura chame o código do usuário). Outros mecanismos de retorno de chamada incluem membros que recebem representantes, membros virtuais e plug-ins baseados em interface. Dados de estudos de usabilidade indicam que a maioria dos desenvolvedores se sente mais confortável usando eventos do que outros mecanismos de retorno de chamada. Os eventos são bem integrados ao Visual Studio e a muitas linguagens.

É importante notar que existem dois grupos de eventos: eventos gerados antes de um estado do sistema mudar, chamados pré-eventos, e eventos gerados após uma alteração de estado, chamados pós-eventos. Um exemplo de pré-evento seria Form.Closing, que é gerado antes de um formulário ser encerrado. Um exemplo de pós-evento seria Form.Closed, que é gerado depois de um formulário ser encerrado.

✔️ Use o termo "gerar” para eventos em vez de "lançar" ou "disparar".

✔️ Use System.EventHandler<TEventArgs> em vez de criar manualmente novos representantes para serem usados como manipuladores de eventos.

✔️ CONSIDERE usar uma subclasse de EventArgs como argumento do evento, a menos que você tenha certeza absoluta de que o evento nunca precisará carregar nenhum dado para o método de manipulação de eventos. Nesse caso, use diretamente o tipo EventArgs.

Ao enviar uma API usando EventArgs diretamente, não é possível adicionar dados que serão transportados com o evento sem interromper a compatibilidade. No caso de uma subclasse, mesmo que completamente vazia de início, é possível adicionar propriedades quando necessário.

✔️ Use um método virtual protegido para gerar cada evento. Isso é aplicável somente a eventos não estáticos em classes não seladas, não a structs, classes seladas ou eventos estáticos.

O objetivo do método é fornecer uma maneira de uma classe derivada manipular o evento usando uma substituição. A substituição é uma maneira mais flexível, rápida e natural de lidar com eventos de classe base em classes derivadas. Por convenção, o nome do método deve começar com "On" e ser seguido pelo nome do evento.

A classe derivada pode optar por não chamar a implementação base do método na substituição. Para preparar-se para isso, não inclua nenhum processamento no método necessário a fim de que a classe base funcione corretamente.

✔️ Defina um parâmetro para o método protegido que gera um evento.

O parâmetro deve ser nomeado e e escrito como a classe de argumento de evento.

❌ Não transmita nulo como remetente ao gerar um evento não estático.

✔️ Transmita nulo como remetente ao gerar um evento estático.

❌ Não transmita nulo como o parâmetro de dados do evento ao gerar um evento.

Transmita EventArgs.Empty quando não quiser transmitir nenhum dado para o método de manipulação de eventos. Os desenvolvedores esperam que esse parâmetro não seja nulo.

✔️ Considere gerar eventos que o usuário final possa cancelar. Isso só se aplica a pré-eventos.

Use System.ComponentModel.CancelEventArgs ou a subclasse respectiva como argumento de evento para permitir que o usuário final cancele eventos.

Design de manipulador de eventos personalizado

Há casos em que EventHandler<T> não pode ser usado, como quando a estrutura precisa trabalhar com versões anteriores do CLR, que não fornecem suporte a genéricos. Nesses casos, pode ser necessário projetar e desenvolver um representante de manipulador de eventos personalizado.

✔️ Use um tipo de retorno nulo para manipuladores de eventos.

Um manipulador de eventos pode invocar diversos métodos de manipulação de eventos, possivelmente em diversos objetos. Se os métodos de manipulação de eventos pudessem retornar um valor, haveria diversos valores de retorno para cada chamada de evento.

✔️ Use object como o tipo do primeiro parâmetro do manipulador de eventos e chame-o de sender.

✔️ Use System.EventArgs ou a respectiva subclasse como o tipo do segundo parâmetro do manipulador de eventos e chame-o de e.

❌ Não tenha mais de dois parâmetros em manipuladores de eventos.

Portions © 2005, 2009 Microsoft Corporation. Todos os direitos reservados.

Reimpresso com permissão da Pearson Education, Inc. das Diretrizes de Design do Framework: convenções, linguagens e padrões para bibliotecas do .NET reutilizável, 2ª edição por Krzysztof Cwalina e Brad Abrams, publicado em 22 de outubro de 2008 por Addison-Wesley Professional como parte da série de desenvolvimento do Microsoft Windows.

Confira também