7

In VB.NET there is a keyword 'shadows'. Let's say I have a base class called 'Jedi' and a derived class called 'Yoda' which inherits from 'Jedi'. If I declare a method in 'Jedi' called 'ForcePush' and shadow that out in 'Yoda' then when calling the method on an instance of the 'Yoda' class, it will ignore the base class implementation and use the derived class' implementation. However if I have an instance of 'Yoda' that was declared originally as of type 'Jedi', i.e. Dim j as Jedi = new Yoda(), and called the 'ForcePush' method on the instance, it will use the Jedi implementation.

Now let's say I have an event that is called 'UsingForce' which is raised when the 'ForcePush' method is called, and I shadow the event out in the derived class (this is because 'Yoda' has an interface 'IForcePowers' that declares this event) and each class raises it's respective event.

If I have an instance of 'Yoda' that is declared as type 'Jedi' (like above) and I put an event handler on the 'UsingForce' event of 'Jedi', and then the 'ForcePush' method is called in the 'Yoda' class, will this event handler be reached?

dnatoli
  • 6,972
  • 9
  • 57
  • 96
  • 1
    This is an awesome question. I'm going to use the Jedi/Yoda example the next time I have to explain inheritance. – David Sep 08 '09 at 03:20
  • 1
    David: I agree, it is awesome, so awesome that it distracted me from the actual question and I ended up just thinking about star wars for a while. – Noon Silk Sep 08 '09 at 04:02
  • 1
    Sorry guys, I'll try and make my questions a little less awesome next time! :) – dnatoli Sep 08 '09 at 04:22

1 Answers1

3

Using the shadows keyword in VB.NET means that you are declaring an entirely new member that exists outside of any inheritance heirarchy that exists. This is why that keyword (and the associated practice) is generally regarded as "smelly" (though some people object to this particular term, I find it quite appropriate). What is the reasoning behind this pattern of "shadowing things out"? This approach is usually reserved for circumstances where there is no other way to go about accomplishing what you need. Was inheriting and overriding the methods not an option?

In any event, if you "shadow out" the event in a lower class, then no, there is no possible way for a class farther up the inheritance chain to trigger the event directly, as they have no idea that it even exists.

Adam Robinson
  • 182,639
  • 35
  • 285
  • 343
  • You can't override events, and the reason I need to implement it in the derived class is because the derived class uses an interface that exposes the event, so that when I declare and object of type 'IForcePowers' with events, I can add a static handler to the object. – dnatoli Sep 08 '09 at 04:23
  • If an interface declares any member--be it a function, property, or event--and a member with a matching name and signature is already implemented either in the implementing class or in one of its base classes, then that member will automatically count toward the interface implementation. IE, if I were to declare an interface called IText with a Text property typed as a string, then I could inherit from any control and declare that it implements the IText interface without any additional code, since a string Text property already exists. – Adam Robinson Sep 08 '09 at 12:37
  • 2
    @AdamRobinson: No. You have to explicitly specify the string-exposing property that is supposed to implement the interface / member in question with an `Implements` keyword (in this case followed by `IText.Text`). That is the problem - and the problem is specific to events (since they cannot be declared `Overridable`), so using methods or properties as examples is misleading. – d7samurai Feb 12 '13 at 04:33