Partekatu bidez


Diseño de eventos

Nota:

Este contenido se reimprime con permiso de Pearson Education, Inc. de Directrices de diseño de frameworks: Convenciones, expresiones y patrones para bibliotecas reutilizables de .NET, 2ª edición. Esa edición fue publicada en 2008, y el libro ha sido totalmente revisado en la tercera edición. Parte de la información de esta página puede estar obsoleta.

Los eventos son la forma más común de callbacks (construcciones que permiten que el framework llame al código de usuario). Otros mecanismos de devolución de llamada son, por ejemplo, los miembros que toman delegados, los miembros virtuales y los complementos basados en interfaz. Los datos de los estudios de facilidad de uso indican que la mayoría de los desarrolladores se sienten más cómodos con los eventos que con los otros mecanismos de devolución de llamada. Los eventos están bien integrados con Visual Studio y muchos lenguajes.

Es importante tener en cuenta que hay dos grupos de eventos: eventos generados antes de que cambie un estado del sistema, denominados eventos previos y eventos generados después de que cambie un estado, denominados eventos posteriores. Un ejemplo de evento previo sería Form.Closing, que se genera antes de cerrar un formulario. Un ejemplo de evento posterior sería Form.Closed, que se genera después de cerrar un formulario.

✔️ Use el término "generar" para los eventos en lugar de "activar" o "desencadenar".

✔️ Utilice System.EventHandler<TEventArgs> en lugar de crear manualmente nuevos delegados para usarlos como controladores de eventos.

✔️ CONSIDERE la posibilidad de usar una subclase de EventArgs como argumento de evento, a menos que esté absolutamente seguro de que el evento nunca tendrá que llevar datos al método de control de eventos, en cuyo caso puede usar el EventArgs tipo directamente.

Si envía una API mediante EventArgs directamente, nunca podrá agregar datos que se lleven con el evento sin interrumpir la compatibilidad. Si usa una subclase, aunque inicialmente esté completamente vacía, podrá agregar propiedades a la subclase cuando sea necesario.

✔️ Use un método virtual protegido para generar cada evento. Esto solo se aplica a eventos no estáticos en clases no selladas, no a estructuras, clases selladas o eventos estáticos.

El propósito del método es proporcionar una manera para que una clase derivada controle el evento mediante una invalidación. La invalidación es una forma más flexible, rápida y natural de controlar eventos de clase base en clases derivadas. Por convención, el nombre del método debe comenzar por "On" y seguirse con el nombre del evento.

La clase derivada puede decidir no llamar a la implementación base del método en su invalidación. Prepárese para ello sin incluir ningún procesamiento en el método necesario para que la clase base funcione correctamente.

✔️ Tome un parámetro para el método protegido que genera un evento.

El parámetro debe denominarse e y debe escribirse como la clase de argumento de evento.

❌ NO pase NULL como remitente al generar un evento no estático.

✔️ Pase NULL como emisor al generar un evento estático.

❌ NO pase NULL como parámetro de datos de evento al generar un evento.

Debe pasar EventArgs.Empty si no desea pasar ningún dato al método de control de eventos. Los desarrolladores esperan que este parámetro no sea NULL.

✔️ CONSIDERE la posibilidad de generar eventos que el usuario final pueda cancelar. Esto solo se aplica a eventos previos.

Use System.ComponentModel.CancelEventArgs o su subclase como argumento de evento para permitir que el usuario final cancele los eventos.

Diseño del controlador de eventos personalizado

Hay casos en los que EventHandler<T> no se puede usar, como cuando el marco necesita trabajar con versiones anteriores de CLR, que no admitieron genéricos. En tales casos, es posible que tenga que diseñar y desarrollar un delegado de controlador de eventos personalizado.

✔️ Use un tipo de valor devuelto de void para los controladores de eventos.

Un controlador de eventos puede invocar varios métodos de control de eventos, posiblemente en varios objetos. Si se permitían métodos de control de eventos devolver un valor, habría varios valores devueltos para cada invocación de evento.

✔️ Use object como el tipo del primer parámetro del controlador de eventos y asígnele el nombre sender.

✔️ Use System.EventArgs o su subclase como el tipo del segundo parámetro del controlador de eventos y asígnele el nombre e.

❌ NO tenga más de dos parámetros en los controladores de eventos.

© Partes 2005, 2009 de Microsoft Corporation. Todos los derechos reservados.

Reimpreso con permiso de Pearson Education, Inc. de Framework Design Guidelines: Convenciones, Idiomas y Patrones para Bibliotecas .NET Reusables, 2ª Edición por Krzysztof Cwalina y Brad Abrams, publicado el 22 de octubre de 2008 por Addison-Wesley Professional como parte de la Serie Desarrollo de Microsoft Windows.

Consulte también