This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Method Overlaoding questions/doubt

 
Abhay Agarwal
Ranch Hand
Posts: 1375
Eclipse IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

I am not able to understand the behaviour of below mentioned codes

======================================
Code A -

class Parent {
String message = "parent";
void say() {
System.out.println(message);
}
}

class Child extends Parent {
String message = "child";
}

public class Test {
public static void main(String[] args) {
new Child().say();
}
}

Output is - parent

====================================

Code B -

class Parent {
Integer get() {
return 1;
}
}

class Child extends Parent {
Number get() {
return 2;
}
}

public class Test {
public static void main(String[] args) {
Parent yo = new Child();
System.out.println(yo.get());
}
}


Output is - 1

=============================

Code C

class Grandparent {
String name = "grandparent";
void act() {
System.out.println(name);
}
}

class Parent extends Grandparent {
String name = "parent";
}

public class Test {
public static void main(String[] args) {
Parent yo = new Parent();
yo.act();
}
}


Output is - grandparent


=======================

Thanks
 
Ryan Beckett
Ranch Hand
Posts: 192
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Shashank Rudra
Ranch Hand
Posts: 131
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ryan can we say that Code C case is similar to Code A case.
 
Ryan Beckett
Ranch Hand
Posts: 192
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There similar in that the subclass in each example doesn't override its inherited methods, so polymorphism isn't applied to either. So, yes.
 
Abhay Agarwal
Ranch Hand
Posts: 1375
Eclipse IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ryan

I am not clear about explanation given by you for for Code sample A and C.

For Code Sample B , we are saying that since ploymorphism does not work here so calling method will decide based on Reference type ?

Thanks
 
Ryan Beckett
Ranch Hand
Posts: 192
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ken Truitt
Ranch Hand
Posts: 124
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ryan Beckett
Ranch Hand
Posts: 192
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yeah, I didn't even pay attention to the message subject. Your code seems to suggest your trying to use polymorphism. Which is it? You didn't overload any methods.
 
Abhay Agarwal
Ranch Hand
Posts: 1375
Eclipse IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ryan and Ken

Thanks for all your reply
I have now understood the concept.

Thanks
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic