Remedo de eventos en .NET

En VB.NET hay una palabra clave 'sombras'. Digamos que tengo una clase base llamada 'Jedi' y una clase derivada llamada 'Yoda' que hereda de 'Jedi'. Si declaro un método en 'Jedi' llamado 'ForcePush' y sombreo en 'Yoda', cuando invoque el método en una instancia de la clase 'Yoda', ignorará la implementación de la clase base y usará la implementación de la clase derivada ' . Sin embargo, si tengo una instancia de 'Yoda' que fue declarada originalmente como del tipo 'Jedi', es decir, Dim j as Jedi = new Yoda(), y llamé al método 'ForcePush' en la instancia, utilizará la implementación de Jedi.Remedo de eventos en .NET

Ahora digamos que tengo un evento que se llama 'UsingForce' que se genera cuando se llama al método 'ForcePush', y sombreo el evento en la clase derivada (esto es porque 'Yoda' tiene una interfaz ' IForcePowers 'que declara este evento) y cada clase plantea su evento respectivo.

Si tengo una instancia de 'Yoda' que está declarada como tipo 'Jedi' (como arriba) y pongo un manejador de eventos en el evento 'UsingForce' de 'Jedi', entonces el método 'ForcePush' es llamado en la clase 'Yoda', ¿se alcanzará este manejador de eventos?

Fuente

2009-09-08 link664

Esta es una pregunta increíble. Voy a usar el ejemplo de Jedi/Yoda la próxima vez que tenga que explicar la herencia. – David

David: Estoy de acuerdo, es increíble, tan increíble que me distrajo de la pregunta real y terminé pensando en star wars por un tiempo. –

Lo siento chicos, intentaré hacer que mis preguntas sean un poco menos impresionantes la próxima vez. :) – link664

El uso de la palabra clave shadows en VB.NET significa que está declarando un miembro completamente nuevo que existe fuera de cualquier jerarquía de herencia que exista. Esta es la razón por la que esa palabra clave (y la práctica asociada) generalmente se considera "huele mal" (aunque algunas personas se oponen a este término en particular, me parece bastante apropiado). ¿Cuál es el razonamiento detrás de este patrón de "sombrear las cosas"? Este enfoque generalmente se reserva para las circunstancias en las que no hay otra forma de lograr lo que necesita. ¿Heredar y anular los métodos no era una opción?

En cualquier caso, si "ocultas" el evento en una clase inferior, entonces no, no hay forma posible para que una clase más arriba en la cadena de herencia desencadene el evento directamente, ya que no tienen idea de que incluso existe.

Fuente

2009-09-08 03:01:57

No puede anular eventos, y la razón por la que necesito implementarlo en la clase derivada es porque la clase derivada usa una interfaz que expone el evento, de modo que cuando declaro y hago un objeto de tipo 'IForcePowers' con eventos, Puedo agregar un controlador estático al objeto. – link664

Si una interfaz declara cualquier miembro, ya sea una función, propiedad o evento, y un miembro con un nombre y una firma coincidentes ya está implementado en la clase implementadora o en una de sus clases base, ese miembro automáticamente contar para la implementación de la interfaz. IE, si tuviera que declarar una interfaz llamada IText con una propiedad Text escrita como una cadena, entonces podría heredar de cualquier control y declarar que implementa la interfaz IText sin ningún código adicional, ya que una propiedad Text de cadena ya existe. –

@ AdamRobinson: No. Tiene que especificar explícitamente la propiedad de exposición de cadena que se supone que implementa la interfaz/miembro en cuestión con una palabra clave 'Implements' (en este caso, seguida de' IText.Text'). Ese es el problema, y el problema es específico de los eventos (ya que no se pueden declarar como 'Anulables'), por lo que usar métodos o propiedades como ejemplos es engañoso. – d7samurai

Respuesta

Cuestiones relacionadas