You didn't override say() in Code A, so polymorphism doesn't apply.
You didn't correctly override get() in Code B (return values must be the same or covariant), so polymorphism doesn't apply.
In code C, you are not handling a subtype with a super type this time. The method that will be called is dependent on the object, not the reference. In this case GrandParent.act() will be called.
Can't explain it any better than that. In all the examples you either didn't override the method or you didn't do it correctly. If you didn't override the methods, then the method to be called will be based on the reference type.
Ahh in B, you having non-matching return types
In A and C, you didn't override and polymorphism is only applicable when you've overridden the methods.
Ah, you indicate that the output for 'code B' is 1--but the code under B doesn't compile
because as was mentioned it's an illegal override. It's illegal because all that has changed
is the return type, which renders it neither an override nor an overload.
An exception would be a legal covariant return type. B would have been legal under
this exception if the parent class return type for the method had been Number, and
the child class return type (the overriding return type) had been Integer. But it is the
reverse in the example.
With regard to A and C, in each case the subclass gets a method through "inheritance."
I put that in quotes because I think it is misleading. K&B actually says something to the
effect that a class that inherits a method gets it as though it had been declared in the
class, which is also misleading, I think. A subclass that has a method through inheritance
can invoke the method as if it had been declared in that class, but the method still runs
in the scope of the superclass, so that member vars used in the method will be found
in the superclass, not in the subclass.
So my point is that it is more like a subclass has access to [public, protected, and in
some cases default,] methods of the superclass, than that it has its own copies of superclass
methods as though they were declared in the subclass itself.
And so it doesn't matter whether the method is invoked on a superclass reference holding a
subclass object, or a subclass reference holding a subclass object...member variables
used in the method will always be located first in the superclass method, because the
method is running in the superclass scope.
Your subject is "Method Overlaoding [sic] questions/doubt." Easy--it's not an overload if
the argument list doesn't change.