Shadowing events in .NET

In VB.NET è presente una parola chiave 'shadows'. Diciamo che ho una classe base chiamata 'Jedi' e una classe derivata chiamata 'Yoda' che eredita da 'Jedi'. Se dichiaro un metodo in 'Jedi' chiamato 'ForcePush' e l'ombra in 'Yoda', quindi quando si chiama il metodo su un'istanza della classe 'Yoda', ignorerà l'implementazione della classe base e utilizzerà l'implementazione della classe derivata . Tuttavia, se ho un'istanza di "Yoda" dichiarata inizialmente come tipo "Jedi", ovvero Dim j as Jedi = new Yoda(), e chiamata il metodo "ForcePush" sull'istanza, verrà utilizzata l'implementazione Jedi.Shadowing events in .NET

Ora diciamo che ho un evento chiamato 'UsingForce' che viene generato quando viene chiamato il metodo 'ForcePush' e oscuro l'evento nella classe derivata (questo perché 'Yoda' ha un'interfaccia ' IForcePowers 'che dichiara questo evento) e ogni classe aumenta il rispettivo evento.

Se ho un'istanza di 'Yoda' che è dichiarata come tipo 'Jedi' (come sopra) e ho inserito un gestore di eventi nell'evento 'UsingForce' di 'Jedi', e quindi il metodo 'ForcePush' è chiamato nella classe 'Yoda', questo gestore di eventi sarà raggiunto?

fonte

2009-09-08 link664

Questa è una domanda fantastica. Userò l'esempio Jedi/Yoda la prossima volta che devo spiegare l'ereditarietà. – David

David: Sono d'accordo, è fantastico, così fantastico che mi ha distratto dalla domanda vera e ho finito per pensare a Star Wars per un po '. –

Scusate ragazzi, proverò a rendere le mie domande un po 'meno fantastiche la prossima volta! :) – link664

Utilizzare la parola chiave shadows in VB.NET significa che si sta dichiarando un membro completamente nuovo che esiste al di fuori di qualsiasi gerarchia ereditaria esistente. Questo è il motivo per cui quella parola chiave (e la pratica associata) è generalmente considerata "puzzolente" (anche se alcune persone si oppongono a questo particolare termine, trovo che sia del tutto appropriato). Qual è il ragionamento dietro questo schema di "shadowing things out"? Questo approccio è solitamente riservato a circostanze in cui non vi è altro modo per realizzare ciò che è necessario. Stava ereditando e sovrascrivendo i metodi non un'opzione?

In ogni caso, se "offuschi" l'evento in una classe inferiore, quindi no, non esiste un modo possibile per una classe più in alto nella catena di ereditarietà per attivare direttamente l'evento, poiché non hanno idea che esiste anche.

fonte

2009-09-08 03:01:57

Non è possibile sovrascrivere gli eventi e il motivo per cui è necessario implementarlo nella classe derivata è perché la classe derivata utilizza un'interfaccia che espone l'evento, in modo che quando dichiaro e oggetto di tipo "IForcePowers" con eventi, Posso aggiungere un gestore statico all'oggetto. – link664

Se un'interfaccia dichiara un membro (sia esso una funzione, una proprietà o un evento) e un membro con un nome e una firma corrispondenti è già implementato nella classe di implementazione o in una delle sue classi base, tale membro automaticamente contare per l'implementazione dell'interfaccia. Ad esempio, se dovessi dichiarare un'interfaccia denominata IText con una proprietà Text digitata come stringa, potrei ereditare da qualsiasi controllo e dichiarare che implementa l'interfaccia IText senza alcun codice aggiuntivo, poiché esiste già una proprietà String di testo. –

@AdamRobinson: No. Devi specificare esplicitamente la proprietà che espone le stringhe che dovrebbe implementare l'interfaccia/membro in questione con una parola chiave 'Implements' (in questo caso seguita da' IText.Text'). Questo è il problema - e il problema è specifico degli eventi (dato che non possono essere dichiarati "Overridable"), quindi usare metodi o proprietà come esempi è fuorviante. – d7samurai

Shadowing events in .NET

risposta

Problemi correlati