Oops, yes of course. But the static modifier is the basic issue here -
getters/setters should also be used for dynamic binding.
Michael
www.mammothsoftware.com
"Build Swing Applications in 5 minutes"
>> Inheritance - dynamic binding at runtime - does not work for static
>> variables or static methods. If you remove the "static" modifier you
>> will
>> see the behavior you expect.
>
> No, there is no dynamic binding with instance variables.
>> Inheritance - dynamic binding at runtime - does not work for static
>> variables or static methods. If you remove the "static" modifier you will
>> see the behavior you expect.
> No, there is no dynamic binding with instance variables.
No, but implicitly, the OP's code compiled, so is
it then okay to reuse an instance variable name in
a subclass? I'd guess, if so, that the subclass
and superclass _each_ have an instance of the same
named variable, but that there is an issue of the
subclass's version _hiding_ the superclass's version,
and vice versa. Then show(), being a superclass
routine, would see only the superclass version of
the instance, and since cat.show() is executing the
superclass's show(), not having overridden it, it is
doing so in the superclass's environment, where type
is zero.
Is that just me being confused, or is that somewhat
close to reality?
xanthian.
Torkel Franzen - 10 Jan 2006 16:31 GMT
> Then show(), being a superclass
> routine, would see only the superclass version of
> the instance, and since cat.show() is executing the
> superclass's show(), not having overridden it, it is
> doing so in the superclass's environment, where type
> is zero.
Right, so if we don't want to override show in every subclass, it's
not a good idea to hide the declaration of type. It makes good sense
that every animal has a type, which tells what kind of animal it is,
so we just let every subclass inherit that variable, and give it a
suitable value in the constructor for each subclass.
Torkel Franzen - 11 Jan 2006 08:18 GMT
> No, but implicitly, the OP's code compiled, so is
> it then okay to reuse an instance variable name in
[quoted text clipped - 8 lines]
> doing so in the superclass's environment, where type
> is zero.
Right. Instead of my earlier nonsensical (and canceled) suggestions,
I would suggest the following. It is perfectly reasonable to have a
field in the class Animal saying which kind of animal it is. But if we
also think different kinds of animals sufficiently different to warrant
introducing corresponding subclasses, we will need to both override
show in those classes and to give the inherited field its proper value
in constructors. I can't think of any good reason for hiding the
declaration of the field in the subclasses. The class Animal should
be made abstract if its show method will never be used anyway.
The OP reflected that it shouldn't be necessary to override show,
since the method is intended to do exactly the same thing in Animal
and in all its subclasses - let an animal say which kind of animal
it is. But given that there is no dynamic binding of fields, it has
to be done this way.