Another Polymorphism question

[tshad]

But the class which you think doesn't have a Draw method, actually does.
You didn't define one, so it inherited the version in its base class
(which might have been defined in the base class or inherited from yet
another base).

Got it.

Thanks,

Tom

 

[tshad]

[...]

Without virtual methods, to get different results from different
objects,
you have to know the full type of the object and call that specific
method
using that type. But, with virtual methods, that allows code to treat
the
object using the simplest, least-derived type in that object's
inheritance
hierarchy that still supports the functionality needed. In the case of
code that needs the ToString() method, this least-derived type is the
base
type for every single other type -- Object -- and code can use that
without knowing _anything_ else about the type of the object.

But you wouldn't get the least derived method (as in the case, of the
ToString() method) but the most derived method, right?

You'll get the most-derived override of that virtual method, yes.

if A was the base class and E was the object we are using:

A a = new E();
a.ToString();

You would get the most derived ToString() method starting from A until it
hit either a "new" or the E object. Correct?

For what it's worth, I really think you should forget about the question
of hiding virtual methods until you understand the more basic issues of
virtual methods. Code should almost never be hiding _any_ methods in the
first place, never mind hiding virtual methods. It's _much_ more
intersting to talk about why virtual methods are so useful in the first
place, than to talk about how one might mess up a perfectly good virtual
method by hiding it.

I agree.

But if I didn't understand that part of it, what would be the point. I just
want to make sure I get that part, which I do now.

If this is the case, all that a does is give you acces to less properties
and methods and you can't even be sure which methods will actually be
used
unless you follow the chain yourself? So what does it buy you?

Um. It buys you _everything_! Polymorphism is one of the most powerful
features of OOP.

"All that a [sic] does is give you access to less properties and
ethods" -- you're thinking of inheritance in the wrong way. Sure,
sometimes inheritance is about taking some base class and adding
features. But just as often, it's about taking some base class and
making its existing features work _better_ or in some specific way. In
those situations, you lose nothing by referring only to the base type.

"You can't even be sure which methods will actually be used" -- who
can't? The code using the base type can't, you're right. But that's an
_advantage_. It doesn't need to know. You can have one little place in
your code that knows the exact implementation you want to use, and then
the rest of the code only has to worry about the base type. This is much
better than having to put conditional code everywhere that you need
different behavior depending on some precondition.

Even in terms of the code where the implementation is chosen, it may well
not be important at all where the method that implements the virtual
method is. If it _is_ important, then the implementation is almost
certainly in the class being instantiated in the first place, and so
knowing what the implementation is isn't not very complicated at all. If
you assume no hiding of virtual methods, then the implementation is in the
class you're instantiating; that's why you chose that class to represent
you!.

You may find it useful to look at how interfaces are used. They are in a
way a special-case of inheriting a virtual method, in that the interface
is basically a whole class full of virtual methods, and only virtual
methods. If you can understand why interfaces are useful, then you should
be able to understand why virtual methods in other contexts are useful.

And if you can't understand why interfaces are useful, may I suggest that
you start there. Make sure you understand that, and then move on to
virtual methods.

Sounds good.

Thanks,

Tom